亚洲精品视频免费观看,亚洲日本成人网,亚洲免费二区

我认为最好的MYSQL备䆾方式

无风之雨 — Tue, 11 Apr 2006 04:47:00 GMT

    要备份MYSQL�Q�很多�h用mysqldump�Q�其实这�U�方式，导出的文件是最大的�Q�导入的旉��是最久的。命令是方便的，但真正发生错误的时候，恢复效率很低�?br />    我主张，另外找一台比较空闲的机器�Q�来做数据库的备份。这台机器作以下用途：

   它是��L��据库带的slave数据库群里面的一収ͼ�每天凌晨定时启动同步数据�Q�等�q�上bin-log�q�全部执行后�Q�停止同步，�q�用select * into outfile��数据全部导出成文�g�Q��ƈ且在每周的某一天，清除掉主数据库上已经同步好的bin-log�Q�以��保��盘�I�间不被log占满�?br />
   为此�Q�我写了3个脚本，分别执行1、启动mysql�Q�追log�Q�然后停止slave�Q?、导出全部数据库全部文�g到文�Ӟ��3、删除主数据库的log

---------------------------------------------------------------------------------------
#!/bin/bash
#readMasterMysql.sh
CHECK_MYSQL=0
/home/mysql/bin/mysqld_safe &
until [ "$CHECK_MYSQL" = "1" ]
do
sleep 10
CHECK_MYSQL=`/home/mysql/bin/mysql -uroot -e"show slave status"|awk '{if($14==$21)print "1"}'|tail -n1`
done
/home/mysql/bin/mysql -uroot -e"slave stop"
/home/script/backupMysql.sh
/home/mysql/bin/mysqladmin shutdown
WEEK=`date "+%w"`
if [ $WEEK = "5" ]
then
    /home/script/purgeLog.sh
fi

------------------------------------------------------------------------------
#!/bin/bash
#purgeLog.sh
LOG_FILE=/home/mysql/data/master.info
DB_SERVER=`sed -n '4p' $LOG_FILE`
DB_USER=`sed -n '5p' $LOG_FILE`
DB_PASS=`sed -n '6p' $LOG_FILE`
DB_LOGFILE=`sed -n '2p' $LOG_FILE`
/home/mysql/bin/mysql -h$DB_SERVER -u$DB_USER -p"$DB_PASS" -e"purge master logs to '$DB_LOGFILE'"

------------------------------------------------------------------------------
#!/bin/bash
#backupMysql.sh
database=$1
table=$2
MYSQL_CLIENT="/home/mysql/bin/mysql -uroot --default-character-set=gbk"
MYSQL_DUMP="/home/mysql/bin/mysqldump -d -uroot --default-character-set=gbk"
OUTPUT_PATH=/date/backup
for databases in `$MYSQL_CLIENT -e "show databases"|grep -v Database`
do
if [ "$#" = "0" -o "$database" = "$databases" ] ; then
        mkdir -p -m777 $OUTPUT_PATH/$databases/
        $MYSQL_DUMP $databases > $OUTPUT_PATH/$databases/$databases.sql
        for tables in `$MYSQL_CLIENT -e "show tables" $databases|grep -v Tables_in_`
        do
        if [ "$#" = "0" -o "$#" = "1" -o "$table" = "$tables" ] ; then
                mv -f $OUTPUT_PATH/$databases/$tables $OUTPUT_PATH/$databases/$tables.old
                $MYSQL_CLIENT -e "select * into outfile '$OUTPUT_PATH/$databases/$tables' from $tables" $databases
        fi
        done
fi
done

无风之雨 2006-04-11 12:47 发表评论

oracle到mysql的迁�U�，函数部分

无风之雨 — Tue, 11 Apr 2006 04:16:00 GMT

to_date(?, 'YYYY-MM-DD HH24:MI:SS')"
STR_TO_DATE('2003-15-10 00:00:00','%Y-%m-%d %H:%i:%s'); //格式不对�Q�会�q�回NULL

to_char(create_time,'yyyy-MM-dd')
DATE_FORMAT(create_time,'%Y-%m-%d')

sysdate
now()或者CURRENT_TIMESTAMP //'1997-12-15 23:50:26',��的时候，timestamp�c�d��可以指定default CURRENT_TIMESTAMP

sysdate - 7 //7天前
now()-INTERVAL 7 DAY

select * from (select .... where rownumstart
limit [start,] length

substr(productInfor,1,20)
SUBSTRING('Quadratically',5,6) //SUBSTRING(str,pos,len)

instr(str,substr,pos,index)
instr(str,substr) 或�?locate(substr,str,pos)
// 没有相对应的语法�Q�但一般情况，�q�个是和substr�l�合��h��用的�?br />//如果是str="2005-10-01"取中间的10�q�样的需要，oracle是substr(str,instr(str,'-',1,1)+1,instr(str,'-',1,2)-instr(str,'-',1,1)-1)
那在mysql里面�Q�可以试试这样SUBSTRING_INDEX(SUBSTRING_INDEX(str,'-',2),'-',-1),意思就是取�W�二�?之前的str后（2005-10�Q�，再取倒数�W�一�?之后的内�?/p>

oracle的nvl�Q�ss,dd�Q�函数在mysql中怎么实现�Q?
�{�：ifnull(ss,dd)

无风之雨 2006-04-11 12:16 发表评论

无风之雨 — Tue, 11 Apr 2006 04:15:00 GMT

Mysql到oracle�E�序�q�移的注意事��?摘抄)
有很多应用项�? 刚�v步的时候用MYSQL数据库基本上能实现各�U�功能需求，随着应用用户的增多，
数据量的增加�Q�MYSQL渐渐地出��C��堪重负的情况�Q�连接很慢甚臛_��机，于是��有把数据从MYSQL�q�到
ORACLE的需求，应用�E�序也要相应做一些修攏V��本人�ȝ��Z��下几�Ҏ��意事��，希望对大家有所帮助�?

1�Q?自动增长的数据类型处�?
MYSQL有自动增长的数据�c�d��Q�插入记录时不用操作此字�D�，会自动获得数据倹{�?
ORACLE没有自动增长的数据类型，需要徏立一个自动增长的序列��P��插入记录时要把序列号的下一�?
��D��于此字段�?

CREATE SEQUENCE 序列��L��名称 (最好是表名+序列��h��? INCREMENT BY 1 START WITH 1
MAXVALUE 99999 CYCLE NOCACHE;
其中最大的值按字段的长度来�? 如果定义的自动增长的序列�?NUMBER(6) , 最大��gؓ999999
INSERT 语句插入�q�个字段��gؓ: 序列��L��名称.NEXTVAL

2. 单引��L��处理
MYSQL里可以用双引号包起字�W�串�Q�ORACLE里只可以用单引号包�v字符丌Ӏ�在插入和修改字�W�串
前必��d��单引��L��替换�Q�把所有出现的一个单引号替换成两个单引号�?

3. ��页的SQL语句的处�?
MYSQL处理��页的SQL语句比较��单，用LIMIT 开始位�|? 记录个数�Q�PHP里还可以用SEEK定位到结�?
集的位置�?
ORACLE处理��页的SQL语句��比较繁琐了。每个结果集只有一个ROWNUM字段标明它的位置, �q�且只能
用ROWNUM<100, 不能用ROWNUM>80�?
以下是经�q�分析后较好的两�U�ORACLE��页SQL语句( ID是唯一关键字的字段�?)�Q?
语句一�Q?
SELECT ID, [FIELD_NAME,...] FROM TABLE_NAME WHERE ID IN ( SELECT ID FROM (SELECT
ROWNUM AS NUMROW, ID FROM TABLE_NAME WHERE 条�g1 ORDER BY 条�g2) WHERE NUMROW > 80 AND
NUMROW < 100 ) ORDER BY 条�g3;

语句二：
SELECT * FROM (( SELECT ROWNUM AS NUMROW, c.* from (select [FIELD_NAME,...] FROM
TABLE_NAME WHERE 条�g1 ORDER BY 条�g2) c) WHERE NUMROW > 80 AND NUMROW < 100 ) ORDER BY 条�g3;

4�Q?长字�W�串的处�?
长字�W�串的处理ORACLE也有它特�D�的地方。INSERT和UPDATE时最大可操作的字�W�串长度��于�{�于
4000个单字节, 如果要插入更长的字符�? 误��虑字段用CLOB�c�d��Q�方法借用ORACLE里自带的DBMS_LOB�E�序
包。插入修改记录前一定要做进行非�I�和长度判断�Q�不能�ؓ�I�的字段值和��出长度字段值都应该提出警告,
�q�回上次操作�?

5. 日期字段的处�?
MYSQL日期字段分DATE和TIME两种�Q�ORACLE日期字段只有DATE�Q�包含年月日时分�U�信息，用当前数据库
的系�l�时间�ؓSYSDATE, �_��到秒�Q�或者用字符串�{换成日期型函数TO_DATE(�?001-08-01�?’YYYY-MM-DD�?
�q?�?�?24��时:分钟:�U?的格式YYYY-MM-DD HH24:MI:SS TO_DATE()�q�有很多�U�日期格�? 可以参看
ORACLE DOC.
日期型字�D��{换成字符串函数TO_CHAR(�?001-08-01�?’YYYY-MM-DD HH24:MI:SS�?

日期字段的数学运��公式有很大的不同�?
MYSQL扑ֈ��d��前时�?天用
DATE_FIELD_NAME > SUBDATE�Q�（NOW�Q�）�Q�INTERVAL 7 DAY�Q?
ORACLE扑ֈ��d��前时�?天用
DATE_FIELD_NAME >SYSDATE - 7;

6. �I�字�W�的处理
MYSQL的非�I�字�D�也有空的内容，ORACLE里定义了非空字段��׃��容许有空的内宏V�?
按MYSQL的NOT NULL来定义ORACLE表结�? 导数据的时候会产生错误。因此导数据时要对空字符�q�行�?
断，如果为NULL或空字符�Q�需要把它改成一个空格的字符丌Ӏ?

7. 字符串的模糊比较
MYSQL里用字段�?like '%字符�?'
ORACLE里也可以�?字段�?like '%字符�?' 但这�U�方法不能��用烦�? 速度不快
用字�W�串比较函数 instr(字段�?'字符�?)>0 会得到更�_��的查扄��?

8. �E�序和函数里�Q�操作数据库的工作完成后��h��意结果集和指针的释放�?

有兴��可以看MYSQL��理员指�?

无风之雨 2006-04-11 12:15 发表评论

MYSQL�Ҏ��函数

无风之雨 — Tue, 11 Apr 2006 04:13:00 GMT

1、用mysql内置函数转换ip地址和数�?br />利用两个内置函数
inet_aton:��ip地址转换成数字型
inet_ntoa:��数字型转换成ip地址

2、用Mysql内置函数来�{化unix旉��(�U��?和字�W�串旉��
from_unixtime():1144728462 -> "2006-04-11 12:07:42"
unix_timestamp():"2006-04-11 12:07:42" -> 1144728462

无风之雨 2006-04-11 12:13 发表评论

MYSQL5.1的表分区功能

无风之雨 — Tue, 11 Apr 2006 03:47:00 GMT

Improving Database Performance with Partitioning

A few years ago, I wrote an article entitled "The Foundation of Excellent Performance" (still available at http://www.tdan.com/i016fe03.htm) where I argued against the notion that SQL code was the number one contributor to performance in a database-driven system. Instead, I stated in the article that I firmly believed how good physical database design was far and away the leading component of superior database performance. In addition, I showed that Oracle's own research illustrated how poor design was the main culprit behind database downtime (planned or unplanned). In the years since then, I've not changed my stance and still think that any DBA who wants a high-performance database has got to invest in intelligent and savvy physical design to produce the kind of response times that make end users smile instead of scream.

One of the reasons I'm very excited about the release of MySQL 5.1 is that it contains a potent new weapon for designing supercharged databases that any MySQL DBA should quickly learn how to use and exploit. By smartly using the new 5.1 partitioning feature, a DBA can oftentimes dramatically improve the performance of most any VLDB or data warehouse they happen to be in charge of.
What is Partitioning?

Partitioning is a physical database design technique that many data modelers and DBAs are quite familiar with. Although partitioning can be used to accomplish a number of various objectives, the main goal is to reduce the amount of data read for particular SQL operations so that overall response time is reduced.

There are two major forms of partitioning:

1. Horizontal Partitioning - this form of partitioning segments table rows so that distinct groups of physical row-based datasets are formed that can be addressed individually (one partition) or collectively (one-to-all partitions). All columns defined to a table are found in each set of partitions so no actual table attributes are missing. An example of horizontal partitioning might be a table that contains ten years worth of historical invoice data being partitioned into ten distinct partitions, where each partition contains a single year's worth of data.
2. Vertical Partitioning - this partitioning scheme is traditionally used to reduce the width of a target table by splitting a table vertically so that only certain columns are included in a particular dataset, with each partition including all rows. An example of vertical partitioning might be a table that contains a number of very wide text or BLOB columns that aren't addressed often being broken into two tables that has the most referenced columns in one table and the seldom-referenced text or BLOB data in another.

Before database vendors began building partitioning (mainly horizontal) into their engines, DBAs and data modelers had to physically design separate table structures to hold the desired partitions, which either held redundant data (separate tables with data that were based off a live parent table) or were linked together to form one logical parent object (usually via a view). This practice has since been made obsolete for the most part for horizontal partitioning, although it is sometimes still done for vertical partitioning.
Partitioning in MySQL 5.1

One of the great new features in MySQL 5.1 is support for horizontal partitioning. The really good news about MySQL and the new 5.1 partitioning feature is all the major forms of partitioning are supported:

1. Range - this partitioning mode allows a DBA to specify various ranges for which data is assigned. For example, a DBA may create a partitioned table that is segmented by three partitions that contain data for the 1980's, 1990's, and everything beyond and including the year 2000.
2. Hash - this partitioning mode allows a DBA to separate data based on a computed hash key that is defined on one or more table columns, with the end goal being an equal distribution of values among partitions. For example, a DBA may create a partitioned table that has ten partitions that are based on the table's primary key.
3. Key - a special form of Hash where MySQL guarantees even distribution of data through a system-generated hash key.
4. List - this partitioning mode allows a DBA to segment data based on a pre-defined list of values that the DBA specifies. For example, a DBA may create a partitioned table that contains three partitions based on the years 2004, 2005, and 2006.
5. Composite - this final partitioning mode allows a DBA to perform sub-partitioning where a table is initially partitioned by, for example range partitioning, but then each partition is segmented even further by another method (for example, hash).

There are a number of benefits that come with partitioning, but the two main advantages are:

Increased performance - during scan operations, the MySQL optimizer knows what partitions contain the data that will satisfy a particular query and will access only those necessary partitions during query execution. For example, a million row table may be broken up into ten different partitions in range style so that each partition contains 100,000 rows. If a query is issued that only needs data from one of the partitions, and a table scan operation is necessary, only 100,000 rows will be accessed instead of a million. Obviously, it is much quicker for MySQL to sample 100,000 rows than one million so the query will complete much sooner. The same benefit is derived should index access be possible as local partitioned indexes are created for partitioned tables. Finally, it is possible to stripe a partitioned table across different physical drives by specifying different file system/directory paths for specific partitions. This allows physical I/O contention to be reduced when multiple partitions are accessed at the same time.
Simplified data management - partitioning allows a DBA to have more control over how data is managed inside of the database. By intelligently creating partitions, a DBA can simplify how certain data operations are performed. For example, a DBA can drop specific partitions in a partitioned table while the remaining partitions remain intact (as opposed to crafting a fragmentation-producing mass delete operation for the whole table). Further, partitions are automatically maintained by MySQL so the DBA doesn't have to manually separate and maintain a horizontal partitioning scheme for a table. For example, a DBA can create a history table that holds data for customers that are partitioned across various year ranges, and have those partitioned automatically enforced by the database server with no DBA intervention being necessary.

From a design-for-performance standpoint, we're mainly interested in point one above. By smartly using partitioning and matching the design to properly coded queries, a dramatic performance impact can be realized. Let's take a quick test drive of partitioning in MySQL 5.1 to see this in action. Note that all tests below were done on a Dell Optiplex box with a Pentium 4 3.00GHz processor, 1GB of RAM, running Fedora Core 4 and MySQL 5.1.6 alpha.
Partitioning in Action

To see the positive benefit partitioning can have on a database, let's create identical MyISAM tables that contain date sensitive information, but let's partition one and leave the other a standard heap table. For our partitioned table, we'll partition based on range and use a function that segments the data based on year:

mysql> CREATE TABLE part_tab
-> ( c1 int default NULL,
-> c2 varchar(30) default NULL,
-> c3 date default NULL
->
-> ) engine=myisam
-> PARTITION BY RANGE (year(c3)) (PARTITION p0 VALUES LESS THAN (1995),
-> PARTITION p1 VALUES LESS THAN (1996) , PARTITION p2 VALUES LESS THAN (1997) ,
-> PARTITION p3 VALUES LESS THAN (1998) , PARTITION p4 VALUES LESS THAN (1999) ,
-> PARTITION p5 VALUES LESS THAN (2000) , PARTITION p6 VALUES LESS THAN (2001) ,
-> PARTITION p7 VALUES LESS THAN (2002) , PARTITION p8 VALUES LESS THAN (2003) ,
-> PARTITION p9 VALUES LESS THAN (2004) , PARTITION p10 VALUES LESS THAN (2010),
-> PARTITION p11 VALUES LESS THAN MAXVALUE );
Query OK, 0 rows affected (0.00 sec)

Notice that we designed partitions for a particular year and finished with one catch-all partition to get anything that doesn't fall into any of the specific date partitions. Now let's create a mirror MyISAM table that's not partitioned:

mysql> create table no_part_tab
-> (c1 int(11) default NULL,
-> c2 varchar(30) default NULL,
-> c3 date default NULL) engine=myisam;
Query OK, 0 rows affected (0.02 sec)

Now let's create a procedure (thanks to Peter Gulutzan for the code) that will fill our partitioned table with 8 million rows that distributes data fairly evenly across the various partitions. Once filled, we'll then insert the same data into our non-partitioned MyISAM clone table:

mysql> delimiter //
mysql> CREATE PROCEDURE load_part_tab()
-> begin
-> declare v int default 0;
-> while v < 8000000
-> do
-> insert into part_tab
-> values (v,'testing partitions',adddate('1995-01-01',(rand(v)*36520) mod 3652));
-> set v = v + 1;
-> end while;
-> end
-> //
Query OK, 0 rows affected (0.00 sec)
mysql> delimiter ;
mysql> call load_part_tab();
Query OK, 1 row affected (8 min 17.75 sec)
mysql> insert into no_part_tab select * from part_tab;
Query OK, 8000000 rows affected (51.59 sec)
Records: 8000000 Duplicates: 0 Warnings: 0

With our tables now ready, let's issue a simple date range query on both tables - the non-partitioned table first and then the partitioned table - followed by EXPLAIN's, and see what MySQL does:

mysql> select count(*) from no_part_tab where
-> c3 > date '1995-01-01' and c3 < date '1995-12-31';
+----------+
| count(*) |
+----------+
| 795181 |
+----------+
1 row in set (38.30 sec)

mysql> select count(*) from part_tab where
-> c3 > date '1995-01-01' and c3 < date '1995-12-31';
+----------+
| count(*) |
+----------+
| 795181 |
+----------+
1 row in set (3.88 sec)

mysql> explain select count(*) from no_part_tab where
-> c3 > date '1995-01-01' and c3 < date '1995-12-31'\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: no_part_tab
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 8000000
Extra: Using where
1 row in set (0.00 sec)

mysql> explain partitions select count(*) from part_tab where
-> c3 > date '1995-01-01' and c3 < date '1995-12-31'\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: part_tab
partitions: p1
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 798458
Extra: Using where
1 row in set (0.00 sec)

The power of proper partition and query design can easily be seen as the partitioned table access delivers a whopping 90% response time reduction over the non-partitioned table. The EXPLAIN plans showcase why this is (notice the new EXPLAIN syntax for partitioned objects) as only the first partition in the partitioned table is accessed with all others being skipped.

As a MySQL DBA, it's easy to get excited about the potential benefits that partitioning can provide, but you always want to make sure that the tool you use for database design matches the requirements and scenario of your particular application. Partitioning is best suited for VLDB's that contain a lot of query activity that targets specific portions/ranges of one or more database tables. Of course, other situations lend themselves to partitioning as well (e.g. data archiving, etc.)
A Quick Side Note on Vertical Partitioning

Although MySQL 5.1 automates horizontal partitioning, don't lose sight of vertical partitioning schemes when designing your databases. Although you have to do vertical partitioning manually, you can benefit from the practice in certain circumstances. For example, let's say you didn't normally need to reference or use the VARCHAR column defined in our previously shown partitioned table. Would the elimination of this column help query speed? Let's find out:

mysql> desc part_tab;
+-------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+-------------+------+-----+---------+-------+
| c1 | int(11) | YES | | NULL | |
| c2 | varchar(30) | YES | | NULL | |
| c3 | date | YES | | NULL | |
+-------+-------------+------+-----+---------+-------+
3 rows in set (0.03 sec)

mysql> alter table part_tab drop column c2;
Query OK, 8000000 rows affected (42.20 sec)
Records: 8000000 Duplicates: 0 Warnings: 0

mysql> desc part_tab;
+-------+---------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+---------+------+-----+---------+-------+
| c1 | int(11) | YES | | NULL | |
| c3 | date | YES | | NULL | |
+-------+---------+------+-----+---------+-------+
2 rows in set (0.00 sec)

mysql> select count(*) from part_tab where
-> c3 > date '1995-01-01' and c3 < date '1995-12-31';
+----------+
| count(*) |
+----------+
| 795181 |
+----------+
1 row in set (0.34 sec)

By removing the VARCHAR column from the design, you actually get another 90+% reduction in query response time. Beyond partitioning, this speaks to the effect wide tables can have on queries and why you should always ensure that all columns defined to a table are actually needed.
Wrap Up

A short article like this can't possibly cover all the benefits and mechanics of MySQL 5.1's partitioning, but a few notes of interest include:

* All storage engines support partitioning (MyISAM, Archive, InnoDB, etc.)
* Indexing support for partitioned tables include local indexes, which mirror each partition in a one-to-one scheme. In other words, if a partitioned table has ten partitions, then a local index for that table would also contain ten partitions.
* Metadata regarding partitioned tables can be found in the INFORMATION_SCHEMA database, with a new PARTITIONS table being available.
* All SHOW commands support the return of partitioned table and index metadata.
* Maintenance functions and a number of other operations can be performed on partitions (rather than acting on a full table), including:
o ADD PARTITION
o DROP PARTITION
o COALESCE PARTITION
o REORGANIZE PARTITION
o ANALYZE PARTITION
o CHECK PARTITION
o OPTIMIZE PARTITION
o REBUILD PARTITION
o REPAIR PARTITION

From a performance standpoint, the main take-away is that MySQL 5.1 partitioning is a powerful new tool that can be used in many physical database designs to dramatically improve performance and ease DBA management burdens. For more information on MySQL partitioning, you can visit out the online reference manual at http://dev.mysql.com/doc/refman/5.1/en/partitioning.html and visit the MySQL forums as there is a forum section devoted to partitioning, which can be referenced at http://forums.mysql.com/list.php?106.

Download a copy of MySQL 5.1 (which is now is beta) today and give partitioning a try. I think you will be pleased with all the new possibilities partitioning provides when it comes to creating a top-notch physical database design, which is the number one contributor to overall database performance.

无风之雨 2006-04-11 11:47 发表评论

从头到尾优化MYSQL

无风之雨 — Thu, 30 Mar 2006 09:49:00 GMT

    MYSQL用了好多�q�了�Q�一�ơ次的优化，一�ơ次的顶�q�崩溃的边缘�Q�相信能有这��L��历的��Z��不多。这里我写一点这么多�q�来优化MYSQL的经验�?br />
    让我们从头开�?br />
     什么机器比较适合跑MYSQL�Q�原则就是IO操作一定要快，要少。在�q�个原则下，内存肯定是越大越好，��盘肯定是越快越好�?快硬盘不够快�Q�那��׃��块，做RAID0�?br />    什么操作系�l�比较适合跑MYSQL�Q�我试过Linux,FreeBSD,Solaris。solaris是最差的�Q�因为IO慢，的确比其他两个慢�Q�所以我都不用它了。FBSD和linux哪个好？�q�个我倒是没认真比�q�，感觉上，fbsd的IO比linux快，所以我有一�?千万条记录的mysql跑在fbsd上，讉K��量很高的情况下，感觉�q�是很快。最�q�的��目都统一到Linux下了�Q�感觉mysql在linux下跑�Q�也不错。看�q�不��评��，都说mysql在linux比fbsd快，因�ؓ我没有实际对比，只有各自的体会，所以也不多评论了。不�q�fbsd有一点要注意�Q�它默认的数据段大小只有1G�Q�你惛_��大缓存，��必��重新编译内核，不然会数据段错�?br />    MYSQL5.1都已�l�在��试了，我们应该用什么版本？如果你是新开发一个��品，��?.0�Q�不�q�我没实际用�q�，不好说。我用的最多的�?.23.x�?.1.x。由于没有在相同的环境下��试�Q�所以不敢说哪个版本性能最好。所以还是只推荐5.0或�?.1毕竟是现在MYSQL��L��的，比较有保证�?br />    我最�q�用的最多的�?.1。现在我一般会下蝲for linux�Q�icc�~�译的二�q�制包，以前我一般下源文件自��q��译，源代码编译的是否好，直接影响性能。关于编译mysql的选项�Q��够另外写一��东西了。这里就不提了，有兴��的看看BUILD目录下的东西。现在我常用的是�~�译好的二进制包�Q�因��Z��的编译环境已�l�基本最优化�Q�而且加上icc�~�译器的优化�Q�性能�q�能有一�Ҏ��升�?br />    接着��是my.cnf了。我一般在support-files目录下的my-innodb-heavy-4G.cnf文�g的基��上来修改。对性能影响比较大的�Q�有table_cache�Q�sort_buffer_size�Q�join_buffer_size�Q�query_cache_size�Q�key_buffer_size�Q�read_buffer_size�Q�innodb_additional_mem_pool_size�Q�innodb_buffer_pool_size。用INNODB是肯定的。innodb_additional_mem_pool_size可以大一点，我一般设256M�Q�可以减��不断增加缓存的操作�Q�innodb_buffer_pool_size是初始化的缓存，我觉�?G有点太大了，我們֐�于给操作�pȝ��本��n留点�~�存�I�间。我一般设�?.2G�Q�他自己有需要，也会慢慢涨到2G�?img src ="http://www.aygfsteel.com/ginew/aggbug/38299.html" width = "1" height = "1" />

无风之雨 2006-03-30 17:49 发表评论

无风之雨 — Thu, 30 Mar 2006 09:15:00 GMT

    �|�站�?台MYSQL服务器，其中1台是��L��务器�Q?��C��服务器。主从之间用Replication实时同步�?br />    最�q�，随着�|�站��量的提高，3台服务器在繁忙时�D�都辑ֈ�饱和。通过分析服务器状态，发现服务器都已经开始��用交换分区，此�D无疑会提高服务器对IO的��用频率�?br />
    2��C��服务器中�Q�一�?G内存的服务器处理能力比另外一�?G内存的服务器�?倍，两台服务器的差别�Q�在CPU上差别�ƈ不大�Q�RAID1对IO性能也不会有很大提高。所以断定通过�?G内存升��?G�Q�可以让此机的处理能力大大提高�?br />
    昨天晚上�Q�给2�?G内存的MYSQL加大了内存，�?G�Q�现在MYSQL在最�J�忙时段都已�l�能应付自如了�?br />
    我还特地甌��了一台新机器来做从服务器�Q�配�|�如下：双XEON3.0/4GRAM/2�?46GSCSI做RAID0。估计此机的整体处理能力会非常好�?br />
    �l�论�Q�实际验证了IO对于数据库系�l�性能的媄响。在MYSQL本��n已经无可优化的情况下�Q�加大内存或者把��盘做RAID0能得�?倍的以上的性能提升

无风之雨 2006-03-30 17:15 发表评论