MySQL调优别急着改参数：先把这三件事查清楚

接手一个跑得慢的库，很多人的第一反应是打开配置文件，把能调的参数挨个往上加。我见过不少这样的配置，缓冲池从1G一路调到32G，查询速度没见涨，机器内存先被吃光了。数据库慢的原因通常不在参数上，而在你还没看清它到底慢在哪一步。这篇讲的是排查顺序：先确认瓶颈落在SQL、索引还是硬件，再决定要不要动配置，最后才是选一台撑得住的机器。

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

没有慢查询日志的调优基本等于闭眼开车。开日志的开销很小，但能告诉你哪几条语句在拖后腿。我一般会先把 long_query_time 设成1秒，跑一两天再看。

打开日志之后你会发现，真正拖慢系统的往往就那么几条语句。有些是没走索引的全表扫描，有些是 join 写得太大。把这几条挑出来，比调十个参数都管用。

• long_query_time 先设1秒，观察期结束后再按实际情况收紧
• 把 log_queries_not_using_indexes 打开，能快速暴露没走索引的语句
• 慢日志本身会占磁盘，观察完记得清理或轮转

这一步的代价是要等一两天才有数据，但省下来的时间远超这点等待。

执行计划决定一切，索引不是越多越好

拿到慢语句之后用 EXPLAIN 看一遍。重点看 type 这一列：出现 ALL 就是全表扫描，出现 index 是扫了整个索引树，这两种都要处理。理想状态是 ref 或者 range。

索引能救回大部分查询，但加索引有代价。每多一个索引，写入就多一次维护开销，磁盘占用也跟着涨。我见过一张表上挂了十几个索引，读是快了，插入慢得离谱。取舍很简单：读多写少的表可以多给几个索引，写密集的表要克制。

组合索引的顺序也有讲究。把区分度高的列放前面，能让索引更快定位。如果一条语句同时用到了 where 和 order by，索引设计要兼顾两边，否则排序还是会走文件排序。

这一步是整个调优里最值钱的地方。SQL 和索引改对了，往往能省下加内存、换机器的钱。反过来，如果 SQL 本身写得有问题，堆再多硬件也是白搭。

缓冲池设多大，跟你的数据量挂钩

SQL 和索引都收拾干净了，再回头看内存。InnoDB 的缓冲池是性能大头，但它的合理值取决于你的热数据有多大，不是越大越好。

判断方法很直接：看库的总数据量。如果整库才几个G，缓冲池设到8G到10G通常就能把热数据全装进内存，再多也是闲置。整库几十G、上百G的时候，才需要考虑更大的内存配置。

我一般会先看数据量再定内存，而不是反过来。一台 16G 内存的机器，分给缓冲池8G到10G，剩下的留给系统和连接，这个比例对中小站点多数情况下够用。如果数据量已经远超内存，先考虑归档历史数据，比直接加内存划算。

硬件层面，数据库吃的是内存容量和磁盘 IO。机械盘跑 MySQL 在小数据量下还能忍，一旦热数据超过内存，随机读会拖得很明显，这时候换 SSD 的收益比调参数大得多。选机器的时候，内存和磁盘这两项别省，CPU 反而可以缓一缓——多数中小库的瓶颈不在核数上。

如果库的体量已经上到几百G、并发也压不住，那问题的性质就变了，单机调优的天花板到了。这种情况可以考虑换一台内存更大、磁盘更快的独立服务器，把缓冲池和 IO 都留出余量。像 马来西亚服务器1 这类 E3-1230 / 16G / 20M 的配置，适合中小库做迁移落脚点，月付 $99.00 起步，先把数据量摸清楚再决定要不要往上加。

收尾：按这个顺序做，别跳步

慢查询日志 → EXPLAIN → 索引调整 → 缓冲池，这个顺序不要颠倒。跳过前面直接调参数，等于在没找到病因的情况下先吃药。

具体怎么落地：中小站点先把慢日志开起来观察两天，把 top 几条语句的执行计划看一遍，能加索引解决的先加；数据量在10G以内的，16G内存配8G到10G缓冲池就够了；数据量超过内存装得下的时候，再考虑加内存或换 SSD。如果单机已经压不住，就别在参数上继续磨了，换一台内存和磁盘都宽裕的机器更直接。