MySQL性能优化从入门到实战：慢查询分析与索引优化指南

一、慢查询日志——找到拖慢数据库的元凶

MySQL的慢查询日志是性能优化的第一把钥匙。只要开启它，MySQL会把执行时间超过设定阈值的SQL语句记录下来，让优化工作有的放矢，而不是凭空猜测。先开启慢查询日志，建议在MySQL配置文件中加入以下参数：

slow_query_log = ON
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 1
log_queries_not_using_indexes = ON

long_query_time设置为1秒的意思是任何执行时间超过1秒的查询都会被记录。对于高并发业务，这个阈值可以降到0.5甚至0.1秒。log_queries_not_using_indexes是一个容易被忽略但非常有用的参数，它会把没有使用索引的查询也记录下来，哪怕执行速度很快——因为一张表数据量大了以后，全表扫描终会成为性能瓶颈。

二、用mysqldumpslow分析慢查询

慢查询日志原始格式可读性一般，MySQL自带的mysqldumpslow工具可以汇总分析：

mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log

-s t表示按查询耗时排序，-t 10表示只看排名前10的查询。输出结果会把参数化的SQL语句汇总在一起，比如WHERE id = N中的N被抽象为数字，方便统计同类查询的总耗时。拿到最慢的几个查询之后，就可以针对每条SQL做EXPLAIN分析。

三、EXPLAIN命令——读懂MySQL的执行计划

EXPLAIN是MySQL优化最重要的命令。在慢查询前面加上EXPLAIN关键字，MySQL会告诉你这条SQL是怎么执行的，而不是真正去跑它。输出结果中需要重点关注几个字段：

type字段表示访问类型，从好到差依次是system > const > eq_ref > ref > range > index > ALL。如果看到ALL（全表扫描），说明这张表的查询没走索引，是优化的重点。rows字段是MySQL估算的需要扫描的行数，这个数字越大性能越差。Extra字段里如果出现Using filesort或Using temporary，说明查询需要额外的排序或临时表，通常意味着索引设计不合理。

举个例子，type为ref且rows只有几十行的查询，通常性能不会有问题。但如果看到type是ALL、rows超过十万行，那这条SQL必须建索引才能解决。

四、索引设计的基本原则

很多新手以为索引加得越多越好，其实不然。索引也是有代价的——每个索引都会占用磁盘空间，并且每次INSERT、UPDATE、DELETE操作都需要同时更新索引，影响写入性能。索引设计有几个核心原则：

第一，区分度高的列适合建索引。比如性别字段只有男和女两种值，区分度太低，走索引反而可能不如全表扫描快。第二，最左前缀原则——MySQL的联合索引遵循最左匹配，索引(a, b, c)能加速a、a+b、a+b+c的查询，但查b+c用不上这个索引。第三，不要对频繁更新的列建太多索引，写入性能会显著下降。

五、覆盖索引——减少回表查询

覆盖索引是高阶优化技巧。当查询的所有字段都在索引中时，MySQL可以直接从索引返回结果，不需要回表查询原始数据行。比如有一个索引(col1, col2, col3)，查询SELECT col1, col2, col3 FROM table WHERE col1 = 1就只需要扫描索引，不需要访问数据行，效率极高。在慢查询优化中，可以尝试将SELECT *改为只查询需要的字段，然后创建覆盖索引来满足查询。

六、日常维护与监控

SQL优化不是一次性的工作。定期检查慢查询日志，把新出现的慢查询纳入优化范围。常用的监控手段包括：用SHOW PROCESSLIST查看当前正在执行的查询，发现长时间未完成的可以直接KILL；用SHOW INDEX FROM检查表的索引使用情况；对大表定期执行OPTIMIZE TABLE回收碎片。另外，MySQL 8.0以上的版本提供了Performance Schema，可以更精细地分析数据库内部的性能瓶颈，建议有条件的话开启使用。