慢查询优化需按“日志→执行计划→系统指标→配置硬件”四层排查：先开 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、磁盘、内存这些底层资源卡死。
- 跑
sar -u 1看%wa（I/O wait）是否持续 >20%，再跑sar -d 1看%util是否常驻 95%+——如果是，瓶颈大概率在磁盘，不是 SQL 本身 - 查
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_%'，算缓冲池命中率：(1 - Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests) * 100，低于 95% 就说明热数据没缓住，innodb_buffer_pool_size很可能设小了 - 看锁竞争：
SHOW GLOBAL STATUS LIKE 'Innodb_row_lock_waits'如果每秒增长明显，配合SELECT * FROM information_schema.INNODB_TRX找长事务，别只盯着 SQL，先杀掉卡住的事务 - 别忽略连接数：
SHOW STATUS LIKE 'Threads_connected'对比max_connections，若长期接近上限，可能是应用端没复用连接，而非数据库扛不住
别跳过硬件与配置的“隐性瓶颈”
很多慢查询优化到极致仍卡顿，问题其实在配置和部署层面——这些地方不报错、不告警，但默默拖垮所有 SQL。
-
innodb_flush_method默认是fsync，在 Linux 上会引发双重缓存（OS page cache + InnoDB buffer pool），设成O_DIRECT可避免，但需确认文件系统支持 - redo log 文件太小（如默认 48MB）会导致频繁 checkpoint，写入抖动；建议设为
innodb_log_file_size = 1G~4G（总大小不超过 buffer pool 的 25%） - 大字段（
TEXT/BLOB）和主表混存，会让每次查询都拖着几 MB 数据进出内存；拆到单独扩展表，主表只留 ID 关联 - 跨机房访问？单次网络 RTT 15ms，一个含 3 次交互的查询就至少 45ms——这不是数据库问题，是架构问题，该加代理或读写分离就别硬扛
真正难的不是发现哪条 SQL 慢，而是判断“慢”到底发生在哪一层：是磁盘在等 IO，是 CPU 在算函数，是锁在等释放，还是网络在传包。每个环节的证据链要闭环，否则优化就是蒙眼贴膏药。
