MySQL调优别乱改参数：先把这几个地方查明白

不少站长遇到数据库慢，第一反应是去翻my.cnf，把各种buffer调大一圈。改完重启，发现该慢还是慢，甚至更卡了。问题出在哪？因为大多数时候瓶颈根本不在参数上。

先看慢查询日志，别凭感觉猜

MySQL默认不会记录慢查询，你得先打开它。在配置文件里加上slow_query_log=ON和long_query_time=1，重启后跑一两天业务，再用mysqldumpslow或者pt-query-digest分析日志。十有八九你会发现，拖慢整个库的就是那么一两条SQL。

拿到慢SQL之后，用EXPLAIN看执行计划。重点看type列，如果是ALL全表扫描，那基本就是索引没建对。再看rows列，扫描行数动辄几十万上百万的，加索引的效果立竿见影。

索引不是越多越好，写多读少要权衡

见过有人给每张表的每个字段都建索引，结果插入更新慢得离谱。索引本质上是拿写入性能换查询性能，写多读少的表（比如日志表）索引要克制，读多写少的表（比如配置表）可以适当放开。

• 联合索引注意最左前缀原则，where条件里字段顺序要和索引顺序对得上
• 区分度低的字段（比如性别、状态）单独建索引意义不大
• 用覆盖索引能避免回表，查询只取索引里有的字段时会快很多

如果业务本身读写压力就大，单机MySQL扛不住，可以考虑把数据库放到独立物理服务器上，IO和内存都给足。比如马来西亚服务器1这种E3-1230配16G内存的机型，跑中小型站点的MySQL绰绰有余，吉隆坡机房到东南亚的延迟也低。

连接数和缓存，调对了才有效

max_connections别盲目调大。连接数上去了，每个连接都要占内存，线程切换开销也跟着涨。先看show status里的Threads_connected和Max_used_connections，如果实际用量远低于上限，调大没意义。

innodb_buffer_pool_size是最值得调的参数之一，一般设成物理内存的50%到70%。但前提是你的数据集能装进去，装不进去的话，调多大都会频繁读磁盘。另外记得关注innodb_buffer_pool_hit_rate，低于95%就说明内存不够或者查询太散。

调优是个反复验证的过程，改一个参数、压测一轮、看监控曲线，别一次改十个参数然后不知道是哪个起了作用。先把慢SQL和索引理顺，再动参数，顺序反了就是白忙活。