MySQL调优到底该从哪下手？参数、索引、硬件取舍一次讲清
很多人第一次认真做MySQL调优，都是被慢查询日志逼的。翻日志看到几条3秒以上的SQL，第一反应是加索引，加完发现没好多少，又把锅甩给服务器太弱，准备换机器。我见过不少这样的配置，问题其实卡在没人先弄清楚瓶颈在哪一层——是SQL写法、是参数配错，还是IO真的扛不住。这三层的处理顺序搞反了，钱和时间都会白花。下面按从软到硬的顺序拆开说，每一层都给出能直接动手的判断依据。
先看慢查询日志，别急着加索引
索引不是万能药。一条SQL慢，可能是没走索引，也可能是走了索引但回表太多，还可能是排序、临时表把内存吃光了。
打开慢查询日志是第一步，long_query_time设成1秒就够，别设0.1秒，日志会大到没法看。看日志的时候重点盯两类：扫描行数远大于返回行数的，以及出现Using filesort或者Using temporary的。
加索引之前先看区分度。一个性别字段加索引毫无意义，因为一半的行都是同一个值，优化器干脆不用它。真正值得加的是那种where条件里高频出现、且值分布散的列。
组合索引的字段顺序也有讲究。等值查询的列放前面，范围查询的列放后面，因为范围条件一出现，后面的列就用不上索引了。这点我踩过坑，一条按状态加时间排序的查询，索引写成（时间,状态）就全表扫，反过来写才走索引。
还有一点容易被忽略：索引本身占空间，写多读少的表加太多索引，每次insert都要维护一遍，写入反而变慢。所以加索引这件事，得看这张表是读多还是写多。
参数调优：innodb_buffer_pool_size是重头戏
参数里最值得动手的是innodb_buffer_pool_size，它决定InnoDB能缓存多少数据和索引。这个值给太小，每次查询都去读磁盘，再好的SQL也快不起来。
经验做法是给到物理内存的50%到70%。一台64G内存的机器，如果只跑MySQL，设40G左右是常见的。设完不要重启就完事，还得看InnoDB Buffer Pool的命中率，命中率低于99%说明还得往上加。
第二个要调的是innodb_log_file_size。默认值偏小，写入频繁的库容易出现checkpoint抖动。一般设成1G到2G，但改了之后要正常关闭实例再改，不能直接重启。
连接数也别乱开。max_connections设成几千，看着很豪气，实际上每个连接都要占内存，连接一多反而把buffer pool挤掉，性能断崖式下跌。按实际并发量乘以1.5来估，比拍脑袋设个大数字靠谱。
参数调完记得用show status看几个计数器，比如Innodb_buffer_pool_read_requests和Innodb_buffer_pool_reads的比值，比凭感觉判断准得多。
硬件这层：什么时候该换机器，换什么
软件层都调过了还是慢，才轮到看硬件。判断依据很直接：buffer pool命中率一直上不去，磁盘IO util长期跑满，CPU的iowait占比高，这几条同时出现，基本就是IO拖后腿。
换机器的时候，内存优先级高于CPU。MySQL对主频敏感但不吃核心数，双路E5配64G内存跑中小规模的库，比单路高主频配32G要稳。磁盘优先选SSD，机械盘跑InnoDB，随机写能拖垮整个实例。
拿秀米云的马来西亚服务器4举例，Gold-6133双路加64G内存、20M带宽，月付319美元，这种配置跑一个日活几万的业务库基本够用，主频高对单条复杂查询的帮助比堆核明显。如果库大、写入猛，带宽和IO压力都上来了，可以看马来西亚大带宽服务器VI，E5-2698v4双路、64G内存、100M带宽，月付403.50美元，带宽宽裕，做主从同步和备份传输不占业务流量。
预算再紧一点，马来西亚站群I是E5-2683v4双路、64G内存、20M带宽，月付259美元，内存给够，适合数据量中等、以读为主的场景。选机器这件事我的取舍是：先租一个月看真实负载曲线，再决定要不要升配，比一次性买顶配省得多。
还有一条：从库和备份节点不必和主库同规格。从库只承担读和同步，内存给主库的六成左右往往就够，省下来的预算留给主库的SSD更划算。
调优的顺序比技巧更重要
把三层理清楚之后，动手顺序就很明确了：先看慢查询日志定位具体SQL，再调buffer pool这类核心参数，最后才评估硬件。跳过前两步直接换机器，大概率花了钱问题还在。
可执行的结论给在这里。日活几千以内、数据量几十G的库，先把索引和参数调好，普通配置的独立服务器就能撑住。数据量上百G、写入频繁、buffer pool命中率长期低于99%的，该上64G内存配SSD的机器，别在参数上反复折腾。至于那种单表几亿行、又不做分表的，换什么机器都是治标，分库分表得排上日程。
调优没有一劳永逸的配置，业务量涨了，瓶颈会从一层挪到另一层。养成定期看慢查询日志的习惯，比背参数值管用。