SQL慢查询优化核心是定位瓶颈、验证假设、针对性优化，90%问题源于索引缺失、连接不当、数据量预估偏差或隐式转换；必须看EXPLAIN，重点关注type、rows和Extra字段，结合FORMAT=JSON深入分析成本与扫描行数，并验证索引是否真生效。
SQL慢查询排查不是靠猜，核心是定位瓶颈、验证假设、针对性优化。真实场景中，90%的慢查询问题出在索引缺失、表连接方式不当、数据量预估偏差或写法隐式转换上——而不是服务器配置或数据库版本。
看执行计划：别跳过 EXPLAIN 这一步
不看执行计划就调优，等于蒙眼修车。重点盯三块：
• type 字段：出现 ALL 或 index（全表/全索引扫描）基本就是大问题；
• rows 字段：显示预估扫描行数，若远超实际返回结果（比如查10条却扫50万行），说明索引没走对或失效；
• Extra 信息：出现 Using filesort、Using temporary 是性能红灯，尤其二者同时出现，大概率要重构排序逻辑或加覆盖索引。
小技巧：用 EXPLAIN FORMAT=JSON 查看详细成本估算，关注 query_cost 和各表的 rows_examined_per_scan，比传统格式更能暴露驱动表选择错误。
查索引是否“真生效”：字段顺序、类型、NULL 都可能让索引沉默
常见假象：建了索引，EXPLAIN 却显示 key=NULL。
• 字段顺序错：复合索引 (a,b,c)，查询条件只有 WHERE c = ? 或 WHERE b = ?，索引完全无效；
• 类型不一致：字段是 VARCHAR(20)，但 WHERE 里传了数字（如 WHERE user_id = 123），触发隐式转换，索引失效；
• 允许 NULL 没处理：索引字段含大量 NULL，而查询写成 WHERE status IS NOT NULL，部分旧版本 MySQL 可能放弃使用该索引；
• 函数操作绕过索引：写成 WHERE DATE(create_time) = '2024-01-01'，应改为 WHERE create_time >= '2024-01-01' AND create_time 。
连表逻辑要“反常识”：小表驱动大表只是基础，真正关键在连接字段和过滤时机
很多人死记“小表驱动大表”，但真实慢查询常因连接字段无索引或 WHERE 条件下推失败。
• 先确认每张参与 JOIN 的表，连接字段（ON 子句）是否都有索引；
• 把高过滤性的条件尽量写在 JOIN 之前（即驱动表的 WHERE 中），避免先笛卡尔积再过滤；
• 复杂多表关联时，用 STRAIGHT_JOIN 强制连接顺序（需谨慎测试），比依赖优化器更可控；
• 如果某张中间表结果集很大（EXPLAIN 显示 rows 超百万），考虑拆成子查询 + 临时表，或用物化 CTE（MySQL 8.0+）固化中间结果。
不只是 SQL 写法：检查数据分布与统计信息是否“过期”
优化器依赖表的统计信息做执行计划决策。如果某张表刚导入 1000 万新数据，但 ANALYZE TABLE 没跑过，优化器仍按旧数据量估算，可能选错索引甚至走错连接算法。
• 定期执行 ANALYZE TABLE 表名;（尤其在大批量写入后）；
• 查看统计信息是否更新：SELECT * FROM mysql.innodb_table_stats WHERE database_name='xxx' AND table_name='yyy';；
• 对于分区表或超大单表，可手动指定采样比例：ANALYZE TABLE t SAMPLE_RATE=0.5;（MySQL 8.0.23+）。
基本上就这些。慢查询不是玄学，是可追踪、可验证、可归因的过程。每次优化后记得对比执行时间、扫描行数、CPU/IO 消耗（可通过 Performance Schema 或 slow log 中的 Rows_examined 和 Query_time 验证）。不复杂，但容易忽略细节。
