慢查询优化需按“日志→执行计划→系统指标→配置硬件”四层排查：先开slow_query_log捕获超1s查询；再用EXPLAIN分析type、key、rows及Extra；接着查sar、缓冲池命中率、锁等待和连接数；最后审视innodb_flush_method、redo log大小、大字段存储及网络架构。
先看慢查询日志，别一上来就 EXPLAIN
90% 的性能问题，源头就在没走索引的 SQL 上。但你不能靠猜——得让 MySQL 自己“招供”。slow_query_log 是最直接的线索源，不是辅助工具，是第一现场。
- 临时开启：执行
SET GLOBAL slow_query_log = 1，再设long_query_time = 1（单位秒），立刻捕获 >1s 的查询 - 别信默认值 10 秒——线上业务里，超过 200ms 就该警惕，1 秒已是严重信号
- 日志路径用
SHOW VARIABLES LIKE 'slow_query_log_file'查，别硬猜；分析时优先用mysqldumpslow -s t -t 10（按耗时排前 10） - 坑点：MySQL 重启后
SET GLOBAL失效；若要长期开，必须改my.cnf并重启，但生产环境慎用——日志体积暴涨、IO 压力反升
用 EXPLAIN 看执行计划，重点盯 type、key、rows
EXPLAIN 不是“看看就行”，它暴露的是优化器实际怎么干活。同一句 SQL，在不同数据量、不同索引下，执行路径可能天差地别。
-
type出现ALL？说明全表扫描，立刻检查 WHERE 条件字段有没有索引，或是否因函数（如WHERE DATE(create_time) = '2025-01-01'）导致索引失效 -
key是NULL？不是没建索引，很可能是索引列顺序不匹配联合索引的最左前缀，或用了OR拆分导致索引失效 -
rows显示预估扫描 50 万行？哪怕最终只返回 1 行，这 50 万行也已从磁盘/缓冲池里捞过一遍——I/O 和 CPU 都已付出 - 额外注意
Extra：出现Using filesort或Using temporary，说明排序或分组没走索引，正在内存或磁盘上建临时结构
查系统指标，确认瓶颈真在 MySQL 内部
应用层报“查询慢”，不等于 MySQL 在拖后腿。得先排除 CPU、磁盘、内存这些底层资源卡死。
