Mysql数据库优化技术之配置篇、索引篇 （ 必看 必看 转）

转自：Mysql数据库优化技术之配置篇、索引篇 （ 必看 必看 ）

(一)减少数据库访问

对于可以静态化的页面，尽可能静态化

对一个动态页面中可以静态的局部，采用静态化

部分数据可以生成XML，或者文本文件形式保存

使用数据缓存技术，例如： MemCached



(二)优化的检测方法

1.用户体验检测

2.Mysql状态检测

在Mysql命令行里面使用show status命令，得到当前mysql状态。

主要关注下列属性：

key_read_requests (索引读的请求数）(key_buffer_size设置影响)

key_reads（索引读响应数)

Key_blocks_used

Qcache_*

Open_tables(通过table_cache的设置影响)

Opened_tables

table_locks

3. 第三方工具检测

mysqlreporthttp://hackmysql.com/mysqlreport

mytophttp://jeremy.zawodny.com/mysql/mytop/

系统及Mysql的Log

系统命令： top, sar

Mysql的Log: slow_query.log



(三)硬件方面的优化

硬件方面，最容易成为Mysql瓶颈的部分是磁盘，其次是CPU和内存

磁盘方面

使用更快的磁盘，会对Mysql有很好的帮助

使用更多的硬盘，通过Raid，可以提高单块磁盘速度的问题

对于Raid方式，建议采用Raid 0+1 或者 Raid 1+0

CPU

毫无疑问，更高主频的CPU和更多的CPU数量可以给Mysql更

高的性能

内存

更高的内存，往往可以让Mysql中的更多的数据缓存在内存中，

但是，一个重要的因素是，需要有正确的Mysql的配置

网卡

使用千兆网卡及千兆网络

(四)操作系统方面的优化

1.不使用交换区。如果内存不足，增加更多的内存或配置你的系统使用较少内存

2. 不要使用NFS磁盘

3.增加系统和MySQL服务器的打开文件数量

使用ulimit –n 65535

4.增加系统的进程和线程数量。

5.关闭不必要的应用，优化硬盘参数，使用hdparm测试

(五)应用级的优化

1.使用多服务器负载均衡(多台读和写,用复制技术进行数据同步)

2.表的分区 (自定义分区,mysql5.1开始支持自带分区功能)

3.使用数据缓存技术memcached



(六)Mysql配置的优化

1.key_buffer(=512):索引缓冲使用的内存数量

这对MyISAM表来说非常重要,设定在可用内存的25%-30%较好,通过检查状态值 Key_read_requests和 Key_reads,

可以知道key_buffer设置是否合理。比例key_reads / key_read_requests应该尽可能的低，至少是1:100，1:1000更好 ,否则说明 key_buffer 设置有点偏小

2.innodb_buffer_pool_size(= 512):索引缓冲使用的内存数量



3.table_cache (=1024):数据表缓存区的尺寸

每当 MySQL 访问一个表时，如果在表缓冲区中还有空间，该表就被打开并放入其中，这样可以更快地访问表内容。

通过检查运行峰值时间的 Open_tables 和 Opened_tables 状态值，可以决定是否需要调整 table_cache 的值。

如果你发现 open_tables 的值等于 table_cache，并且发现 opened_tables 状态值在不断增长，那么你就需要增加 table_cache 参数值了,

也不能盲目地把 table_cache 参数设置成很大的值，如果设置得太高，可能会造成文件描述符不足，从而造成性能不稳定或者连接失败。

4.sort_buffer_size (=256):指定排序用缓冲区的长度

该参数对应的分配内存是每连接独占！如果有100个连接，那么实际分配的总共排序缓冲区大小为100 × 6 ＝ 600MB。

所以，对于内存在4GB左右的服务器推荐设置为6-8M

5.join_buffer_size :关联查询用缓冲区的长度

4G内存以上，建议大于32M,该参数对应的分配内存也是每连接独享！

6.max_connections (=1024):可以复用的线程数量

允许同时连接MySQL服务器的客户数量 ,可以观察和估计系统在峰值最大的并发连接数来设置

7.thread_cache(=*):可以复用的线程数量

一般设置为CPU数×2

8.innodb_buffer_pool_size(= 512):innodb表缓存池大小

这对Innodb表来说非常重要。Innodb相比MyISAM表对缓冲更为敏感。MyISAM可以在默认的 key_buffer_size 设置下运行的可以，

然而Innodb在默认的innodb_buffer_pool_size 设置下却跟蜗牛似的。

由于Innodb把数据和索引都缓存起来，无需留给操作系统太多的内存，因此如果只需要用Innodb的话则可以设置它高达 70-80% 的可用内存。

一些应用于 key_buffer 的规则有 -- 如果你的数据量不大，并且不会暴增，那么无需把innodb_buffer_pool_size 设置的太大了.

9.innodb_flush_logs_at_trx_commit(=1) :事务提交后的日志刷新模式

是否为Innodb比MyISAM慢1000倍而头大?看来也许你忘了修改这个参数了。默认值是 1，这意味着每次提交的更新事务(或者每个事务之外的语句)都会刷新到磁盘中，

而这相当耗费资源，尤其是没有电池备用缓存时。很多应用程序，尤其是从 MyISAM转变过来的那些，把它的值设置为 2 就可以了，也就是不把日志刷新到磁盘上，

而只刷新到操作系统的缓存上。日志仍然会每秒刷新到磁盘中去，因此通常不会丢失每秒1-2次更新的消耗。如果设置为0就快很多了，不过也相对不安全了,

MySQL服务器崩溃时就会丢失一些事务。设置为2指挥丢失刷新到操作系统缓存的那部分事务.

(七)表的优化

1. 选择合适的数据引擎

MyISAM:适用于大量的读操作的表

InnoDB:适用于大量的写读作的表

2.选择合适的列类型

使用 SELECT * FROM TB_TEST PROCEDURE ANALYSE()可以对这个表的每一个字段进行分析，给出优化列类型建议

3.对于不保存NULL值的列使用NOT NULL，这对你想索引的列尤其重要

4.建立合适的索引

5.使用定长字段,速度比变长要快

(八)建立索引原则

1.合理使用索引

一个Table在一次query中只能使用一个索引,使用EXPLAIN语句来检验优化程序的操作情况

使用analyze帮助优化程序对索引的使用效果做出更准确的预测

2.索引应该创建在搜索、排序、归组等操作所涉及的数据列上

 

3.尽量将索引建立在重复数据少的数据列中，唯一所以最好

例如：生日列，可以建立索引，但性别列不要建立索引

 

4.尽量对比较短的值进行索引

降低磁盘IO操作，索引缓冲区中可以容纳更多的键值，提高命中率

如果对一个长的字符串建立索引，可以指定一个前缀长度

5.合理使用多列索引

如果多个条件经常需要组合起来查询,则要使用多列索引(因为一个表一次查询只能使用一个索引,建立多个单列索引也只能使用一个)

 

6.充分利用最左前缀

也就是要合理安排多列索引中各列的顺序，将最常用的排在前面

 

7.不要建立过多的索引

只有经常应用于where,order by,group by中的字段需要建立索引.

 

8.利用慢查询日志查找出慢查询(log-slow-queries, long_query_time)

 

(九)充分利用索引

1.尽量比较数据类型相同的数据列

 

2.尽可能地让索引列在比较表达式中独立, WHERE mycol < 4 / 2 使用索引,而WHERE mycol * 2 < 4不使用

 

3.尽可能不对查询字段加函数,

如WHERE YEAR(date_col) < 1990改造成WHERE date_col < ’1990-01-01’

WHERE TO_DAYS(date_col) - TO_DAYS(CURDATE()) < cutoff 改造成WHERE date_col < DATE_ADD(CURDATE(), INTERVAL cutoff DAY)

 

4.在LIKE模式的开头不要使用通配符

 

5.使用straight join可以强制优化器按照FROM子句的次序来进行联结,可以select straight join,强制所有联结,也可以select * from a straight join b强制两个表的顺序.

 

6.使用force index强制使用指定的索引.如 select * from song_lib force index(song_name) order by song_name比不用force index效率高

 

7.尽量避免使用MySQL自动类型转换,否则将不能使用索引.如将int型的num_col用where num_col=‘5’

 

(十)SQL语句的优化

1.创建合适的统计中间结果表，降低从大表查询数据的几率

2.尽量避免使用子查询，而改用连接的方式.例如：

SELECT a.id, (SELECT MAX(created) FROM posts WHERE author_id = a.id) AS latest_post

FROM authors a

可以改成：

SELECT a.id, MAX(p.created) AS latest_post

FROM authors AS a

INNER JOIN posts p ON (a.id = p.author_id)

GROUP BY a.id

 

select song_id from song_lib where singer_id in

(select singer_id from singer_lib

where first_char='A'

) limit 2000改成:

select song_id from song_lib a

inner join singer_lib b on a.singer_id=b.singer_id and first_char='A' limit 2000

 

3.插入判断重复键时,使用ON DUPLICATE KEY UPDATE :

insert into db_action.action_today(user_id,song_id,action_count) values(1,1,1) ON DUPLICATE KEY UPDATE action_count=action_count+1;

 

4.避免使用游标

游标的运行效率极低，可以通过增加临时表，运用多表查询，多表更新等方式完成任务,不要使用游标.

 

(十一)使用Explain分析SQL语句使用索引的情况

当 你在一条SELECT语句前放上关键词EXPLAIN，MySQL解释它将如何处理SELECT，提供有关表如何联结和以什么次序联结的信息,借助于 EXPLAIN，可以知道什么时候必须为表加入索引以得到一个使用索引来寻找记录的更快的SELECT,你也能知道优化器是否以一个最佳次序联结表。为了 强制优化器对一个SELECT语句使用一个特定联结次序，增加一个STRAIGHT_JOIN子句。 。

EXPLAIN命令的一般语法是：EXPLAIN <SQL命令> 如：explain select * from a inner join b on a.id=b.id

EXPLAIN的分析结果参数详解:

1.table：这是表的名字。

2.type：连接操作的类型。

system:表中仅有一条记录（实际应用很少只有一条资料的表)

const:表最多有一个匹配行,用于用常数值比较PRIMARY KEY或UNIQUE索引的所有部分时,

如：select * from song_lib where song_id=2(song_id为表的primary key)

eq_ref:对于每个来自于前面的表的行组合，从该表中用UNIQUE或PRIMARY KEY的索引读取一行,

如：select * from song_lib a inner join singer_lib b on a.singer_id=b.singer_id（b的type值为eq_ref)

ref:对于每个来自于前面的表的行组合，从该表中用非UNIQUE或PRIMARY KEY的索引读取一行

如：select * from song_lib a inner join singer_lib b on a.singer_name=b.singer_name和

select * from singer_lib b where singer_name=‘ccc’ （b的type值为ref,因为b.singer_name是普通索引)

ref_or_null:该联接类型如同ref，但是添加了MySQL可以专门搜索包含NULL值的行,

如：select * from singer_lib where singer_name=‘ccc’ or singer_name is null

index_merge:该联接类型表示使用了索引合并优化方法

Key： 它显示了MySQL实际使用的索引的名字。如果它为空（或NULL），则MySQL不使用索引。

key_len： 索引中被使用部分的长度，以字节计。

 

3.ref：ref列显示使用哪个列或常数与key一起从表中选择行

4.rows： MySQL所认为的它在找到正确的结果之前必须扫描的记录数。显然，这里最理想的数字就是1。

5.Extra：这里可能出现许多不同的选项，其中大多数将对查询产生负面影响。一般有：

using where：表示使用了where条件

using filesort: 表示使用了文件排序,也就是使用了order by子句，并且没有用到order by 里字段的索引，从而需要

额外的排序开销，所以如果出现using filesort就表示排序的效率很低，需要进行优化,比如采用强制索引

的方法(force index)

===============================================

mysql 优化 （show variables， show status）。

 

安装好mysql后，配制文件应该在/usr /local/mysql/share/mysql目录中，配制文件有几个，有my- huge.cnf my-medium.cnf my-large.cnf my-small.cnf,不同的流量的网站和不同配制的服务器环境，当然需要有不同的配制文件了。

一般的情 况下，my-medium.cnf这个配制文件就能满足我们的大多需要；一般我们会把配置文件拷贝到/etc/my.cnf 只需要修改这个配置文件就可以了，使用mysqladmin variables extended-status –u root –p 可以看到目前的参数，有３个配置参数是最重要的，即key_buffer_size,query_cache_size,table_cache。

key_buffer_size只对MyISAM表起作用，

key_buffer_size 指定索引缓冲区的大小，它决定索引处理的速度，尤其是索引读的速度。一般我们设为16M,实际上稍微大一点的站点　这个数字是远远不够的，通过检查状态值 Key_read_requests和Key_reads,可以知道key_buffer_size设置是否合理。比例key_reads / key_read_requests应该尽可能的低，至少是1:100，1:1000更好（上述状态值可以使用SHOW STATUS LIKE ‘key_read%’获得）。 或者如果你装了phpmyadmin 可以通过服务器运行状态看到,笔者推荐用phpmyadmin管理mysql，以下的状态值都是本人通过phpmyadmin获得的实例分析:

这个服务器已经运行了20天

key_buffer_size – 128M
key_read_requests – 650759289
key_reads - 79112

比例接近1:8000 健康状况非常好

另外一个估计key_buffer_size的办法　把你网站数据库的每个表的索引所占空间大小加起来看看以此服务器为例:比较大的几个表索引加起来大概125M 这个数字会随着表变大而变大。

从4.0.1开始，MySQL提供了查询缓冲机制。使用查询缓冲，MySQL将SELECT语句和查询结果存放在缓冲区中，今后对于同样的SELECT语句（区分大小写），将直接从缓冲区中读取结果。根据MySQL用户手册，使用查询缓冲最多可以达到238%的效率。

通过调节以下几个参数可以知道query_cache_size设置得是否合理

Qcache inserts
Qcache hits
Qcache lowmem prunes
Qcache free blocks
Qcache total blocks

Qcache_lowmem_prunes 的值非常大，则表明经常出现缓冲不够的情况,同时Qcache_hits的值非常大，则表明查询缓冲使用非常频繁，此时需要增加缓冲大小 Qcache_hits的值不大，则表明你的查询重复率很低，这种情况下使用查询缓冲反而会影响效率，那么可以考虑不用查询缓冲。此外，在SELECT语 句中加入SQL_NO_CACHE可以明确表示不使用查询缓冲。

Qcache_free_blocks，如果该值非常大，则表明缓冲区中碎片很多query_cache_type指定是否使用查询缓冲

我设置:

query_cache_size = 32M
query_cache_type= 1

得到如下状态值:

Qcache queries in cache 12737 表明目前缓存的条数
Qcache inserts 20649006
Qcache hits 79060095 　看来重复查询率还挺高的
Qcache lowmem prunes 617913　有这么多次出现缓存过低的情况
Qcache not cached 189896 　　
Qcache free memory 18573912　　目前剩余缓存空间
Qcache free blocks 5328 这个数字似乎有点大　碎片不少
Qcache total blocks 30953

如果内存允许32M应该要往上加点

table_cache 指定表高速缓存的大小。每当MySQL访问一个表时，如果在表缓冲区中还有空间，该表就被打开并放入其中，这样可以更快地访问表内容。通过检查峰值时间的 状态值Open_tables和Opened_tables，可以决定是否需要增加table_cache的值。如果你发现open_tables等于 table_cache，并且opened_tables在不断增长，那么你就需要增加table_cache的值了（上述状态值可以使用SHOW STATUS LIKE ‘Open%tables’获得）。注意，不能盲目地把table_cache设置成很大的值。如果设置得太高，可能会造成文件描述符不足，从而造成性能 不稳定或者连接失败。

对于有1G内存的机器，推荐值是128－256。

笔者设置table_cache = 256

得到以下状态:

Open tables 256
Opened tables 9046

虽 然open_tables已经等于table_cache，但是相对于服务器运行时间来说,已经运行了20天，opened_tables的值也非常低。 因此，增加table_cache的值应该用处不大。如果运行了6个小时就出现上述值 那就要考虑增大table_cache。

如果你不 需要记录2进制log 就把这个功能关掉，注意关掉以后就不能恢复出问题前的数据了，需要您手动备份，二进制日志包含所有更新数据的语句，其目的是在恢复数据库时用它来把数据尽 可能恢复到最后的状态。另外，如果做同步复制( Replication )的话，也需要使用二进制日志传送修改情况。

log_bin指 定日志文件，如果不提供文件名，MySQL将自己产生缺省文件名。MySQL会在文件名后面自动添加数字引，每次启动服务时，都会重新生成一个新的二进制 文件。此外，使用log-bin-index可以指定索引文件；使用binlog-do-db可以指定记录的数据库；使用binlog-ignore- db可以指定不记录的数据库。注意的是：binlog-do-db和binlog-ignore-db一次只指定一个数据库，指定多个数据库需要多个语 句。而且，MySQL会将所有的数据库名称改成小写，在指定数据库时必须全部使用小写名字，否则不会起作用。

关掉这个功能只需要在他前面加上#号

#log-bin

开启慢查询日志( slow query log ) 慢查询日志对于跟踪有问题的查询非常有用。它记录所有查过long_query_time的查询，如果需要，还可以记录不使用索引的记录。下面是一个慢查询日志的例子：

开启慢查询日志，需要设置参数log_slow_queries、long_query_times、log-queries-not-using-indexes。

log_slow_queries 指定日志文件，如果不提供文件名，MySQL将自己产生缺省文件名。long_query_times指定慢查询的阈值，缺省是10秒。log- queries-not-using-indexes是4.1.0以后引入的参数，它指示记录不使用索引的查询。笔者设置 long_query_time=10

笔者设置:

sort_buffer_size = 1M
max_connections=120
wait_timeout =120
back_log=100
read_buffer_size = 1M
thread_cache=32
interactive_timeout=120
thread_concurrency = 4

参数说明:

back_log

要 求MySQL能有的连接数量。当主要MySQL线程在一个很短时间内得到非常多的连接请求，这就起作用，然后主线程花些时间(尽管很短) 检查连接并且启动一个新线程。back_log值指出在MySQL暂时停止回答新请求之前的短时间内多少个请求可以被存在堆栈中。只有如果期望在一个短时 间内有很多连接，你需要增加它，换句话说，这值对到来的TCP/IP连接的侦听队列的大小。你的操作系统在这个队列大小上有它自己的限制。 Unix listen(2)系统调用的手册页应该有更多的细节。检查你的OS文档找出这个变量的最大值。试图设定back_log高于你的操作系统的限制将是无效 的。

max_connections

并发连接数目最大，120 超过这个值就会自动恢复，出了问题能自动解决

thread_cache

没找到具体说明，不过设置为32后 20天才创建了400多个线程 而以前一天就创建了上千个线程 所以还是有用的

thread_concurrency

#设置为你的cpu数目x2,例如，只有一个cpu,那么thread_concurrency=2
#有2个cpu,那么thread_concurrency=4
skip-innodb
#去掉innodb支持

代码:
[client]
#password = your_password
port = 3306
socket = /tmp/mysql.sock
#socket = /var/lib/mysql/mysql.sock
# Here follows entries for some specific programs


# The MySQL server
[mysqld]
port = 3306
socket = /tmp/mysql.sock
#socket = /var/lib/mysql/mysql.sock
skip-locking
key_buffer = 128M
max_allowed_packet = 1M
table_cache = 256
sort_buffer_size = 1M
net_buffer_length = 16K
myisam_sort_buffer_size = 1M
max_connections=120
#addnew config
wait_timeout =120
back_log=100
read_buffer_size = 1M
thread_cache=32
skip-innodb
skip-bdb
skip-name-resolve
join_buffer_size=512k
query_cache_size = 32M
interactive_timeout=120
long_query_time=10
log_slow_queries= /usr/local/mysql4/logs/slow_query.log
query_cache_type= 1
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 4
[mysqldump]
quick
max_allowed_packet = 16M


[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates


[isamchk]
key_buffer = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M


[myisamchk]
key_buffer = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M


[mysqlhotcopy]
interactive-timeout

补充

优 化table_cachetable_cache指定表高速缓存的大小。每当MySQL访问一个表时，如果在表缓冲区中还有空间，该表就被打开并放入其 中，这样可以更快地访问表内容。通过检查峰值时间的状态值Open_tables和Opened_tables，可以决定是否需要增加 table_cache的值。如果你发现open_tables等于table_cache，并且opened_tables在不断增长，那么你就需要增 加table_cache的值了（上述状态值可以使用SHOW STATUS LIKE ‘Open%tables’获得）。注意，不能盲目地把table_cache设置成很大的值。如果设置得太高，可能会造成文件描述符不足，从而造成性能 不稳定或者连接失败。对于有1G内存的机器，推荐值是128－256。

案例1：该案例来自一个不是特别繁忙的服务器 table_cache – 512open_tables – 103 opened_tables – 1273 uptime – 4021421 (measured in seconds)该案例中table_cache似乎设置得太高了。在峰值时间，打开表的数目比table_cache要少得多。

案例 2：该案例来自一台开发服务器。table_cache – 64open_tables – 64opened-tables – 431uptime – 1662790 (measured in seconds)虽然open_tables已经等于table_cache，但是相对于服务器运行时间来说，opened_tables的值也非常低。 因此，增加table_cache的值应该用处不大。
案例3：该案例来自一个upderperforming的服务器table_cache – 64 open_tables – 64 opened_tables – 22423uptime – 19538该案例中table_cache设置得太低了。虽然运行时间不到6小时，open_tables达到了最大值，opened_tables的值 也非常高。这样就需要增加table_cache的值。优化key_buffer_sizekey_buffer_size指定索引缓冲区的大小，它决定 索引处理的速度，尤其是索引读的速度。通过检查状态值Key_read_requests和Key_reads，可以知道key_buffer_size 设置是否合理。比例key_reads / key_read_requests应该尽可能的低，至少是1:100，1:1000更好（上述状态值可以使用SHOW STATUS LIKE ‘key_read%’获得）。key_buffer_size只对MyISAM表起作用。即使你不使用MyISAM表，但是内部的临时磁盘表是 MyISAM表，也要使用该值。可以使用检查状态值created_tmp_disk_tables得知详情。对于1G内存的机器，如果不使用 MyISAM表，推荐值是16M（8-64M）。

案例1：健康状况key_buffer_size – 402649088 (384M) key_read_requests – 597579931 key_reads - 56188案例2：警报状态key_buffer_size – 16777216 (16M)key_read_requests – 597579931key_reads - 53832731案例1中比例低于1:10000，是健康的情况；案例2中比例达到1:11，警报已经拉响。

 

================================

Mysql调优中两个重要参数table_cache和key_buffer

本文根据我自己的一点经验，讨论了Mysql服务器优化中两个非常重要的参数，分别是table_cache，key_buffer_size。

  table_cache 指示表高速缓存的大小。当Mysql访问一个表时，如果在Mysql表缓冲区中还有空间，那么这个表就被打开并放入表缓冲区，这样做的好处是可以更快速地 访问表中的内容。一般来说，可以通过查看数据库运行峰值时间的状态值Open_tables和Opened_tables，用以判断是否需要增加 table_cache的值，即如果open_tables接近table_cache的时候，并且Opened_tables这个值在逐步增加，那就要 考虑增加这个值的大小了。

  在mysql默认安装情况下，table_cache的值在2G内存以下的机器中的值默认时256到 512，如果机器有4G内存,则默认这个值是2048，但这决意味着机器内存越大，这个值应该越大，因为table_cache加大后，使得mysql对 SQL响应的速度更快了，不可避免的会产生更多的死锁（dead lock），这样反而使得数据库整个一套操作慢了下来，严重影响性能。所以平时维护中还是要根据库的实际情况去作出判断，找到最适合你维护的库的 table_cache值，有人说：“性能优化是一门艺术”，这话一点没错。大凡艺术品，大都是经过千锤百炼，精雕细琢而成。

   这里还要说明一个问题，就是table_cache加大后碰到文件描述符不够用的问题，在mysql的配置文件中有这么一段提示

引用
“The number of open tables for all threads. Increasing this value increases the number of file descriptors that mysqld requires.
Therefore you have to make sure to set the amount of open files allowed to at least 4096 in the variable "open-files-limit" in” section [mysqld_safe]”
说 的就是要注意这个问题，一想到这里，部分兄弟可能会用ulimit -n 作出调整，但是这个调整实际是不对的，换个终端后，这个值又会回到原始值，所以最好用sysctl或者修改/etc/sysctl.conf文件，同时还 要在配置文件中把open_files_limit这个参数增大，对于4G内存服务器，相信现在购买的服务器都差不多用4G的了，那这个这个 open_files_limit至少要增大到4096，如果没有什么特殊情况，设置成8192就可以了。


   下面说说key_buffer_size这个参数，key_buffer_sizeO表示索引缓冲区的大小，严格说是它决定了数据库索引处理的速度，尤 其是索引读的速度。根据网络一些高手写的文章表示可以检查状态值Key_read_requests和Key_reads，即可知道 key_buffer_size设置是否合理。比例key_reads / key_read_requests应该尽可能的低，至少是1:100，1:1000更好，虽然我还没有找到理论的依据，但是，我在自己维护的几台实际运 行良好的库做过的测试后表明，这个比值接近1：20000，这从结果证明了他们说这话的正确性，我们不妨用之。

后记：
   我前面说过，性能优化是一件细活，影响mysql性能的因素很多，本文中只是选取了其中我认为比较重要的两个参数，期待和网友一起探讨更多mysql性能优化的技术。