先看慢查询日志，别一上来就 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 在算函数，是锁在等释放，还是网络在传包。每个环节的证据链要闭环，否则优化就是蒙眼贴膏药。
