MySQL 配置优化

安装MySQL后，配置文件my.cnf在 /MySQL安装目录/share/mysql目录中，该目录中还包含多个配置文件可供参考，有my-large.cnf ，my-huge.cnf，  my-medium.cnf，my-small.cnf，分别对应大中小型数据库应用的配置。win环境下即存在于MySQL安装目录中的.ini文件。

 

下面列出了对性能优化影响较大的主要变量，主要分为链接请求的变量和缓冲区变量。

1.   链接请求的变量：

1)     max_connections

MySQL的最大链接数，增长该值增长mysqld 要求的文件描述符的数量。若是服务器的并发链接请求量比较大，建议调高此值，以增长并行链接数量，固然这创建在机器能支撑的状况下，由于若是链接数越多，介于MySQL会为每一个链接提供链接缓冲区，就会开销越多的内存，因此要适当调整该值，不能盲目提升设值。

数值太小会常常出现ERROR 1040: Too many connections错误，能够经过’conn%’通配符查看当前状态的链接数量，以定夺该值的大小。

show variables like ‘max_connections’ 最大链接数

show  status like ‘max_used_connections’响应的链接数

以下：

mysql> show variables like ‘max_connections‘;

+———————–+——-+

| Variable_name　| Value |

+———————–+——-+

| max_connections | 256　　|

+———————–+——-+

mysql> show status like ‘max%connections‘;

+———————–+——-+

| Variable_name　      | Value |

+—————————-+——-+

| max_used_connections | 256|

+—————————-+——-+

max_used_connections / max_connections * 100% （理想值≈ 85%） 

若是max_used_connections跟max_connections相同 那么就是max_connections设置太低或者超过服务器负载上限了，低于10%则设置过大。

2)     back_log

MySQL能暂存的链接数量。当主要MySQL线程在一个很短期内获得很是多的链接请求，这就起做用。若是MySQL的链接数据达到max_connections时，新来的请求将会被存在堆栈中，以等待某一链接释放资源，该堆栈的数量即back_log，若是等待链接的数量超过back_log，将不被授予链接资源。

back_log值指出在MySQL暂时中止回答新请求以前的短期内有多少个请求能够被存在堆栈中。只有若是指望在一个短期内有不少链接，你须要增长它，换句话说，这值对到来的TCP/IP链接的侦听队列的大小。

当观察你主机进程列表（mysql> show full processlist），发现大量264084 | unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL 的待链接进程时，就要加大back_log 的值了。

默认数值是50，可调优为128，对于Linux系统设置范围为小于512的整数。 

3)     interactive_timeout

一个交互链接在被服务器在关闭前等待行动的秒数。一个交互的客户被定义为对mysql_real_connect()使用CLIENT_INTERACTIVE 选项的客户。 

默认数值是28800，可调优为7200。 

2.   缓冲区变量

全局缓冲：

4)     key_buffer_size

key_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得知详情。

举例以下：

mysql> show variables like ‘key_buffer_size‘;

+——————-+————+

| Variable_name | Value      |

+———————+————+

| key_buffer_size | 536870912 |

+———— ———-+————+

key_buffer_size为512MB，咱们再看一下key_buffer_size的使用状况：

mysql> show global status like ‘key_read%‘;

+————————+————-+

| Variable_name　  | Value    |

+————————+————-+

| Key_read_requests| 27813678764 |

| Key_reads　　　|  6798830      |

+————————+————-+

一共有27813678764个索引读取请求，有6798830个请求在内存中没有找到直接从硬盘读取索引，计算索引未命中缓存的几率：

key_cache_miss_rate ＝Key_reads / Key_read_requests * 100%，设置在1/1000左右较好

默认配置数值是8388600(8M)，主机有4GB内存，能够调优值为268435456(256MB)。

5)     query_cache_size

使用查询缓冲，MySQL将查询结果存放在缓冲区中，从此对于一样的SELECT语句（区分大小写），将直接从缓冲区中读取结果。

经过检查状态值Qcache_*，能够知道query_cache_size设置是否合理（上述状态值可使用SHOW STATUS LIKE ‘Qcache%’得到）。若是Qcache_lowmem_prunes的值很是大，则代表常常出现缓冲不够的状况，若是Qcache_hits的值也很是大，则代表查询缓冲使用很是频繁，此时须要增长缓冲大小；若是Qcache_hits的值不大，则代表你的查询重复率很低，这种状况下使用查询缓冲反而会影响效率，那么能够考虑不用查询缓冲。此外，在SELECT语句中加入SQL_NO_CACHE能够明确表示不使用查询缓冲。

与查询缓冲有关的参数还有query_cache_type、query_cache_limit、query_cache_min_res_unit。

query_cache_type指定是否使用查询缓冲，能够设置为0、一、2，该变量是SESSION级的变量。

query_cache_limit指定单个查询可以使用的缓冲区大小，缺省为1M。

query_cache_min_res_unit是在4.1版本之后引入的，它指定分配缓冲区空间的最小单位，缺省为4K。检查状态值Qcache_free_blocks，若是该值很是大，则代表缓冲区中碎片不少，这就代表查询结果都比较小，此时须要减少query_cache_min_res_unit。

举例以下：

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> 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　  |

+————————————–+—————+

查询缓存碎片率= 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％，命中率不好，可能写操做比较频繁吧，并且可能有些碎片。

每一个链接的缓冲

6)    record_buffer_size

每一个进行一个顺序扫描的线程为其扫描的每张表分配这个大小的一个缓冲区。若是你作不少顺序扫描，你可能想要增长该值。

默认数值是131072(128K)，可改成16773120 (16M)

7)     read_rnd_buffer_size

随机读缓冲区大小。当按任意顺序读取行时(例如，按照排序顺序)，将分配一个随机读缓存区。进行排序查询时，MySQL会首先扫描一遍该缓冲，以免磁盘搜索，提升查询速度，若是须要排序大量数据，可适当调高该值。但MySQL会为每一个客户链接发放该缓冲空间，因此应尽可能适当设置该值，以免内存开销过大。

通常可设置为16M 

8)     sort_buffer_size

每一个须要进行排序的线程分配该大小的一个缓冲区。增长这值加速ORDER BY或GROUP BY操做。

默认数值是2097144(2M)，可改成16777208 (16M)。

9)     join_buffer_size

联合查询操做所能使用的缓冲区大小

record_buffer_size，read_rnd_buffer_size，sort_buffer_size，join_buffer_size为每一个线程独占，也就是说，若是有100个线程链接，则占用为16M*100

10)  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。内存在4GB左右的服务器该参数可设置为256M或384M。

11)  max_heap_table_size

用户能够建立的内存表(memory table)的大小。这个值用来计算内存表的最大行数值。这个变量支持动态改变，即set @max_heap_table_size=#

这个变量和tmp_table_size一块儿限制了内部内存表的大小。若是某个内部heap（堆积）表大小超过tmp_table_size，MySQL能够根据须要自动将内存中的heap表改成基于硬盘的MyISAM表。

12)  tmp_table_size

经过设置tmp_table_size选项来增长一张临时表的大小，例如作高级GROUP BY操做生成的临时表。若是调高该值，MySQL同时将增长heap表的大小，可达到提升联接查询速度的效果，建议尽可能优化查询，要确保查询过程当中生成的临时表在内存中，避免临时表过大致使生成基于硬盘的MyISAM表。

mysql> 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增长，若是临时表大小超过tmp_table_size，则是在磁盘上建立临时表，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% ＝1.20%，应该至关好了

默认为16M，可调到64-256最佳，线程独占，太大可能内存不够I/O堵塞

13)  thread_cache_size

能够复用的保存在中的线程的数量。若是有，新的线程从缓存中取得，当断开链接的时候若是有空间，客户的线置在缓存中。若是有不少新的线程，为了提升性能能够这个变量值。

经过比较 Connections和Threads_created状态的变量，能够看到这个变量的做用。

默认值为110，可调优为80。 

14)  thread_concurrency

推荐设置为服务器 CPU核数的2倍，例如双核的CPU, 那么thread_concurrency的应该为4；2个双核的cpu, thread_concurrency的值应为8。默认为8

15)  wait_timeout

指定一个请求的最大链接时间，对于4GB左右内存的服务器能够设置为5-10。

3.    配置InnoDB的几个变量

innodb_buffer_pool_size

对于InnoDB表来讲，innodb_buffer_pool_size的做用就至关于key_buffer_size对于MyISAM表的做用同样。InnoDB使用该参数指定大小的内存来缓冲数据和索引。对于单独的MySQL数据库服务器，最大能够把该值设置成物理内存的80%。

根据MySQL手册，对于2G内存的机器，推荐值是1G（50%）。

innodb_flush_log_at_trx_commit

主要控制了innodb将log buffer中的数据写入日志文件并flush磁盘的时间点，取值分别为0、一、2三个。0，表示当事务提交时，不作日志写入操做，而是每秒钟将log buffer中的数据写入日志文件并flush磁盘一次；1，则在每秒钟或是每次事物的提交都会引发日志文件写入、flush磁盘的操做，确保了事务的ACID；设置为2，每次事务提交引发写入日志文件的动做，但每秒钟完成一次flush磁盘操做。

实际测试发现，该值对插入数据的速度影响很是大，设置为2时插入10000条记录只须要2秒，设置为0时只须要1秒，而设置为1时则须要229秒。所以，MySQL手册也建议尽可能将插入操做合并成一个事务，这样能够大幅提升速度。

根据MySQL手册，在容许丢失最近部分事务的危险的前提下，能够把该值设为0或2。

innodb_log_buffer_size

log缓存大小，通常为1-8M，默认为1M，对于较大的事务，能够增大缓存大小。

可设置为4M或8M。

innodb_additional_mem_pool_size

该参数指定InnoDB用来存储数据字典和其余内部数据结构的内存池大小。缺省值是1M。一般不用太大，只要够用就行，应该与表结构的复杂度有关系。若是不够用，MySQL会在错误日志中写入一条警告信息。

根据MySQL手册，对于2G内存的机器，推荐值是20M，可适当增长。

innodb_thread_concurrency=8

推荐设置为 2*(NumCPUs+NumDisks)，默认通常为8