MySql参数优化

MySql参数优化

windows系统配置文件在xxx\MySQL\MySQL Server 下 my.ini

show global status可以列出mysql服务器运行各种状态值，

show variables 查询mysql服务器配置信息语句：

慢查询

mysql> show variables like ‘slow%’;

variable_name	value
log_slow_queries	on
slow_launch_time	2

mysql> show global status like ‘slow%’;

variable_name	value
slow_launch_threads	0
slow_queries	4148

配置中打开了记录慢查询，执行时间超过2秒的即为慢查询，系统显示有4148个慢查询，你可以分析慢查询日志，找出有问题的sql语句，慢查询时间不宜设置过长，否则意义不大，最好在5秒以内，如果你需要微秒级别的慢查询，可以考虑给mysql打补丁：http://www.percona.com/docs/wiki/release:start，记得找对应的版本。 
打开慢查询日志可能会对系统性能有一点点影响，如果你的mysql是主－从结构，可以考虑打开其中一台从服务器的慢查询日志，这样既可以监控慢查询，对系统性能影响又小。

连接数

查询数据库最大连接数 
show variables like ‘max_connections’;

查询数据库响应的最大连接数 
show global status like ‘max_used_connections’;

Max_used_connections / max_connections * 100% ≈ 85% 
最大连接数占上限连接数的85％左右，如果发现比例在10%以下，MySQL服务器连接数上限设置的过高了。

innodb_buffer_pool_size（重要）

Innodb_buffer_pool_size： 这个参数主要缓存innodb表的索引，数据，插入数据时的缓冲。这个值越大，则磁盘IO越少,查询的速度就会越快。这个值太大了就会影响操作系统的性能。一般将该值设为物理内存的80%。

mysql> SHOW GLOBAL STATUS LIKE ‘Innodb_buffer_pool%’;

Variable_name	Value
Innodb_buffer_pool_read_requests	25623124
Innodb_buffer_pool_reads	8204

一共有25623124个索引读取请求，有8204个请求在内存中没有找到直接从硬盘读取索引，计算索引未命中缓存的概率： 
cache_miss_rate = 8204/25623124 = 0.032% 
在0.1%以下都很好（每1000个请求有一个直接读硬盘），如果key_cache_miss_rate在 0.01%以下的话，Innodb_buffer_size分配的过多，可以适当减少。

innodb_buffer_pool_size 大小建议

mysql> SHOW GLOBAL STATUS LIKE ‘Innodb_buffer_pool_pages_data’;

Variable_name	Value
Innodb_buffer_pool_pages_data	1388

1 row in set (0.00 sec) 
mysql> SHOW GLOBAL STATUS LIKE ‘Innodb_buffer_pool_pages_total’;

Variable_name	Value
Innodb_buffer_pool_pages_total	131071

1 row in set (0.00 sec)

mysql> SHOW GLOBAL STATUS LIKE ‘Innodb_page_size’;

Variable_name	Value
Innodb_page_size	16384

1 row in set (0.00 sec) 
‘Innodb_buffer_pool_pages_data’/ ‘Innodb_buffer_pool_pages_total’ 
当结果 > 95% 则增加 innodb_buffer_pool_size， 建议使用 ram total 75% 
当结果 < 95% 则减少 innodb_buffer_pool_size， 
建议 ‘Innodb_buffer_pool_pages_data’ X ‘Innodb_page_size’ X 1.05 / (1024*1024*1024)

mysql（MyISAM）服务器还提供了key_blocks_*参数：

mysql> show global status like ‘key_blocks_u%’;

variable_name	value
key_blocks_unused	0
key_blocks_used	413543

key_blocks_unused表示未使用的缓存簇(blocks)数，key_blocks_used表示曾经用到的最大的blocks数，比如这台服务器，所有的缓存都用到了，要么增加key_buffer_size，要么就是过渡索引了，把缓存占满了。比较理想的设置： 
key_blocks_used / (key_blocks_unused + key_blocks_used) * 100% ≈ 80% 
临时表 
tmp_table_size=14M # 默认为16M，调到64-256最挂 内存中的每个临时表允许的最大大小。如果临时表大小超过该值，临时表将自动转为基于磁盘的表（Disk Based Table）。 如果需要的话并且你有很多group by语句，增大他的值

mysal> show global status like ‘created_tmp%’;

Variable_name	Value
Created_tmp_disk_tables	21197
Created_tmp_files	58
Created_tmp_tables	1771587

每次创建临时表，created_tmp_tables增加，如果是在磁盘上创建临时表，created_tmp_disk_tables也增加,created_tmp_files表示mysql服务创建的临时文件文件数，比较理想的配置是： 
　　created_tmp_disk_tables / created_tmp_tables * 100% <= 25% 
比如上面的服务器created_tmp_disk_tables / created_tmp_tables * 100% ＝ 12%

再看一下mysql服务器对临时表的配置： 
mysql> show variables where variable_name in (‘tmp_table_size’, ‘max_heap_table_size’);

Variable_name	Value
max_heap_table_size	16777216
tmp_table_size	29360128

只有28MB以下的临时表才能全部放内存，超过的就会用到硬盘临时表。

open table

table_open_cache：表示同时打开的表的个数。这个值越大，能同时打开的表的个数就越多。这个值不是越大越好，因为同时打开的表过多会影响操作系统的性能。 
mysql> show global status like ‘open%tables%’;

variable_name	value
open_tables	100
opened_tables	112

open_tables表示打开表的数量，opened_tables表示打开过的表数量，如果opened_tables数量过大，说明配置中 table_open_cache值可能太小，我们查询一下服务器table_cache值：

mysql> show variables like ‘table_open_cache’;

variable_name	value
table_open_cache	2000

比较合适的值为： 
open_tables / opened_tables * 100% >= 85% 
open_tables / table_open_cache* 100% <= 95% 
线程使用情况 
innodb_thread_concurrency=8 # InnoDB内核最大并发线程数, 该参数取值为服务器逻辑CPU数量*2 
thread_cache_size=8 # 缓存的最大线程数。当客户端连接断开时，如果客户端总连接数小于该值，则处理客户端任务的线程放回缓存。在高并发情况下，如果该值设置得太小，就会有很多线程频繁创建，线程创建的开销会变大，查询效率也会下降。一般来说如果在应用端有良好的多线程处理，这个参数对性能不会有太大的提高。

mysql> show global status like ‘thread%’;

Variable_name	Value
Threads_cached	46
Threads_connected	2
Threads_created	570
Threads_running	1

如果我们在mysql服务器配置文件中设置了thread_cache_size，当客户端断开之后，服务器处理此客户的线程将会缓存起来以响应下一个客户而不是销毁（线程池）（前提是缓存数未达上限）。threads_created表示创建过的线程数，如果发现threads_created值过大的话，表明 mysql服务器一直在创建线程，这也是比较耗资源，可以适当增加配置文件中thread_cache_size值，查询服务器 thread_cache_size配置： 
mysql> show variables like ‘thread_cache_size’;

Variable_name	Value
thread_cache_size	10

查询缓存(query cache)

每次插入，更新等操作会将之前的缓存清掉 垂直分割

query_cache_size：查询缓存大小，用于缓存SELECT查询结果。如果有许多返回相同查询结果的SELECT查询，并且很少改变表，可以设置query_cache_size大于0，可以极大改善查询效率。而如果表数据频繁变化，就不要使用这个，会适得其反

query_cache_type：表示查询缓存区的开启状态。0表示关闭，1表示开启。

mysql> show global status like ‘qcache%’;

variable_name	value
qcache_free_blocks	22756
qcache_free_memory	76764704
qcache_hits	213028692
qcache_inserts	208894227
qcache_lowmem_prunes	4010916
qcache_not_cached	13385031
qcache_queries_in_cache	43560
qcache_total_blocks	111212

mysql查询缓存变量解释：

qcache_free_blocks：缓存中相邻内存块的个数。数目大说明可能有碎片。flush query cache会对缓存中的碎片进行整理，从而得到一个空闲块。

qcache_free_memory：缓存中的空闲内存。

qcache_hits：每次查询在缓存中命中时就增大

qcache_inserts：每次插入一个查询时就增大。命中次数除以插入次数就是不中比率。

qcache_lowmem_prunes：缓存出现内存不足并且必须要进行清理以便为更多查询提供空间的次数。这个数字最好长时间来看；如果这个数字在不断增长，就表示可能碎片非常严重，或者内存很少。（上面的 free_blocks和free_memory可以告诉您属于哪种情况） 
qcache_not_cached：不适合进行缓存的查询的数量，通常是由于这些查询不是 select 语句或者用了now()之类的函数。 
qcache_queries_in_cache：当前缓存的查询（和响应）的数量。 
qcache_total_blocks：缓存中块的数量。 
我们再查询一下服务器关于query_cache的配置：

mysql> show variables like ‘query_cache%’;

variable_name	value
query_cache_limit	2097152
query_cache_min_res_unit	4096
query_cache_size	203423744
query_cache_type	on
query_cache_wlock_invalidate	off

各字段的解释： 
query_cache_limit：超过此大小的查询将不缓存 
query_cache_min_res_unit：缓存块的最小大小 
query_cache_size：查询缓存大小 
query_cache_type：缓存类型，决定缓存什么样的查询，示例中表示不缓存 select sql_no_cache 查询 
query_cache_wlock_invalidate：当有其他客户端正在对myisam表进行写操作时，如果查询在query cache中，是否返回cache结果还是等写操作完成再读表获取结果。 
query_cache_min_res_unit的配置是一柄”双刃剑”，默认是4kb，设置值大对大数据查询有好处，但如果你的查询都是小数据查询，就容易造成内存碎片和浪费。 
查询缓存碎片率 = qcache_free_blocks / qcache_total_blocks * 100% 
如果查询缓存碎片率超过20%，可以用flush query cache整理缓存碎片，或者试试减小query_cache_min_res_unit，如果你的查询都是小数据量的话。 
查询缓存利用率 = (query_cache_size - qcache_free_memory) / query_cache_size * 100% 
查询缓存利用率在25%以下的话说明query_cache_size设置的过大，可适当减小；查询缓存利用率在80％以上而且qcache_lowmem_prunes > 50的话说明query_cache_size可能有点小，要不就是碎片太多。 
查询缓存命中率 = (qcache_hits - qcache_inserts) / qcache_hits * 100% 
示例服务器 查询缓存碎片率 ＝ 20.46％，查询缓存利用率 ＝ 62.26％，查询缓存命中率 ＝ 1.94％，命中率很差，可能写操作比较频繁吧，而且可能有些碎片。 
排序使用情况 
Sort_buffer_size：排序缓存区的大小，这个值越大，排序就越快。(Group by 和 Order by) 
查询排序时所能使用的缓冲区大小。注意：该参数对应的分配内存是每连接独占，如果有100个连接，那么实际分配的总共排序缓冲区大小为100 × 6 = 600MB。所以，对于内存在4GB左右的服务器推荐设置为6-8M

mysql> show global status like ‘sort%’;

variable_name	value
sort_merge_passes	0
sort_range	7
sort_rows	5201
sort_scan	25

sort_merge_passes 包括两步。mysql 首先会尝试在内存中做排序，使用的内存大小由系统变量 sort_buffer_size 决定，如果它的大小不够把所有的记录都读到内存中，mysql 就会把每次在内存中排序的结果存到临时文件中，等 mysql 找到所有记录之后，再把临时文件中的记录做一次排序。这再次排序就会增加 sort_merge_passes。 
实际上，mysql 会用另一个临时文件来存再次排序的结果，所以通常会看到 sort_merge_passes 增加的数值是建临时文件数的两倍。因为用到了临时文件，所以速度可能会比较慢，增加 sort_buffer_size 会减少 sort_merge_passes 和 创建临时文件的次数。但盲目的增加 sort_buffer_size 并不一定能提高速度，见 how fast can you sort data with mysql?（引自http://qroom.blogspot.com/2007/09/mysql-select-sort.html，貌似被墙） 
另外，增加record_rnd_buffer_size的值对排序的操作也有一点的好处，参见：http://www.mysqlperformanceblog.com/2007/07/24/what-exactly-is-read_rnd_buffer_size/

文件打开数(open_files)

mysql> show global status like ‘open_files’;

variable_name	value
open_files	16

mysql> show variables like ‘open_files_limit’;

variable_name	value
open_files_limit	4590

比较合适的设置：open_files / open_files_limit * 100% <= 75％ 
表锁情况

mysql> show global status like ‘table_locks%’;

variable_name	value
table_locks_immediate	1708
table_locks_waited	0

　　table_locks_immediate表示立即释放表锁数，table_locks_waited表示需要等待的表锁数，如果 table_locks_immediate / table_locks_waited > 5000，最好采用innodb引擎，因为innodb是行锁而myisam是表锁，对于高并发写入的应用innodb效果会好些。示例中的服务器 table_locks_immediate / table_locks_waited ＝ 235，myisam就足够了。

表扫描情况

mysql> show global status like ‘handler_read%’;

Variable_name	Value
Handler_read_first	5
Handler_read_key	1639
Handler_read_last	0
Handler_read_next	12
Handler_read_prev	0
Handler_read_rnd	202
Handler_read_rnd_next	11605

调出服务器完成的查询请求次数：

mysql> show global status like ‘com_select’;

variable_name	value
com_select	19

计算表扫描率： 
表扫描率 ＝ handler_read_rnd_next / com_select 
如果表扫描率超过4000，说明进行了太多表扫描，很有可能索引没有建好，增加join_buffer_size 值会有一些好处，但最好不要超过8mb。

mysql> show variables like ‘join_buffer_size’;

variable_name	value
join_buffer_size	262144

对于join_buffer_size的优化，由于是每个线程单独分配，因此需要根据最大连接数，机器可用内存来分配,防止内存用尽或OOM 
一般4-8M是一个比较合理的值，对于复杂的连接sql，可以在连接开始前手动指定join_buffer_size大小.

innodb_flush_log_at_trx_commit =1 # 事务相关参数，如果值为1，则InnoDB在每次commit都会将事务日志写入磁盘（磁盘IO消耗较大），这样保证了完全的ACID特性。 设成2对于很多运用，特别是从MyISAM表转过来的是可以的，它的意思是不写入硬盘而是写入系统缓存。日志仍然会每秒flush到硬 盘，所以你一般不会丢失超过1-2秒的更新。设成0会更快一点，但安全方面比较差，即使MySQL挂了也可能会丢失事务的数据。而值2只会在整个操作系统 挂了时才可能丢数据。

Max_connections：表示数据库的最大连接数。这个连接数不是越大越好，因为连接会浪费内存的资源。

innodb_log_buffer_size=2M # InnoDB日志数据缓冲大小，如果缓冲满了，就会将缓冲中的日志数据写入磁盘（flush）。由于一般至少都1秒钟会写一次磁盘，所以没必要设置过大，即使是长事务。

innodb_log_file_size=53M # 每一个InnoDB事务日志的大小。一般设为innodb_buffer_pool_size的25%到100%