MySQL调优别急着改参数，先把这三件事做对

数据库一慢，很多人的第一反应是打开配置文件，把各种buffer往大了调。结果参数改了一堆，问题还在。MySQL调优不是玄学，它有一套明确的排查顺序，顺序错了，力气全白费。

先搞清楚：慢在哪一步

调优之前必须拿到证据。打开慢查询日志，把long_query_time设成1秒甚至更低，跑上一两天，看看哪些SQL反复出现。多数线上库的慢，集中在少数几条语句上。

拿到慢SQL后用EXPLAIN看执行计划。重点盯三列：type是不是ALL（全表扫描）、rows扫了多少行、Extra里有没有Using filesort或Using temporary。这三样出现任意一个，说明SQL本身就有大问题，改参数救不了。

还有一种慢不在SQL，而在连接层。用show processlist看看是不是大量连接卡在Sending data或者Waiting for table metadata lock。前者通常是查询太重，后者往往是被长事务或者DDL堵住了。

索引是收益最高的一步

大部分性能问题靠索引就能解决一大半。原则不复杂：

• WHERE、ORDER BY、GROUP BY用到的列，考虑建联合索引，注意最左前缀。
• 区分度低的列（比如性别、状态）单独建索引意义不大，放在联合索引后面更合适。
• 避免在索引列上做函数运算或隐式类型转换，否则索引直接失效。
• 联合索引不是越多越好，写多读少的表要控制数量，每个索引都有维护成本。

改完索引记得用EXPLAIN再验证一遍，别凭感觉。有时候你以为走索引了，实际还是全表扫。

参数和硬件：最后再动

SQL和索引都理顺了，再回头看配置。innodb_buffer_pool_size是最值得调的，一般设成物理内存的50%到70%。连接数别盲目设大，max_connections过高会导致上下文切换开销暴涨。

如果这些都做完了还是慢，那就是硬件到顶了。磁盘IOPS、内存容量、CPU核数，任何一个成为瓶颈，软件层再怎么优化都是徒劳。这时候该考虑换机器，而不是继续抠参数。

数据库吃磁盘随机读写很凶，选服务器时IO性能和内存容量比CPU更重要。像马来西亚裸机云 X这类双路E5配32G内存的独立服务器，跑中等规模的MySQL实例比较从容；数据量再大一些，可以考虑马来西亚裸机云 XIV，双路Gold 6133加64G内存，缓冲池能开得更大，减少磁盘回表。

调优的本质是找瓶颈，不是堆配置。先定位、再索引、后参数、最后硬件，按这个顺序走，八成问题都能解决。