索引设计是否覆盖了高频查询条件
没有索引或索引失效是 MySQL 慢查最常见原因。重点看
WHERE、
JOIN、
ORDER BY、
GROUP BY中涉及的字段是否被合理索引覆盖。
实操建议：
用EXPLAIN检查执行计划，关注
type是否为
range或更高（避免
ALL），
key是否命中预期索引，
rows是否明显偏大 联合索引要遵循最左前缀原则；
WHERE a = ? AND b > ? ORDER BY c可考虑
(a, b, c)而非只建
(a)避免在索引列上使用函数或表达式，如
WHERE YEAR(create_time) = 2024会导致索引失效，应改写为
WHERE create_time >= '2024-01-01' AND create_time区分
SELECT *和只查必要字段，尤其避免在覆盖索引场景下回表——如果
SELECT id, name能被
(id, name)索引完全满足，就不会访问主键聚簇索引
慢查询是否被有效识别和归因
没开慢日志或阈值设得太高，等于“闭眼调优”。很多性能问题其实就藏在单条 2 秒的查询里，但因为没记录，一直被忽略。
实操建议：
确认已开启：检查slow_query_log = ON，
long_query_time = 1.0（根据业务容忍度调整，OLTP 建议 ≤ 0.5s） 务必打开
log_queries_not_using_indexes = ON，它能暴露那些“没走索引却自以为快”的隐性问题 用
mysqldumpslow或
pt-query-digest分析日志，重点关注
Count高 +
Query_time avg不低的语句，而不是只盯最大单次耗时 注意连接来源：同一条 SQL 在不同客户端（如应用直连 vs 连接池复用）下执行计划可能不同，
EXPLAIN FORMAT=TRADITIONAL的结果未必等于真实执行路径
buffer pool 和连接配置是否匹配实际负载
innodb_buffer_pool_size设太小，大量物理读拖垮吞吐；设太大，又可能引发系统 OOM 或 swap。连接数也不是越多越好——超量空闲连接会争抢 mutex，反而降低并发处理能力。
实操建议：
innodb_buffer_pool_size一般设为物理内存的 50%–75%，但必须留足空间给 OS、其他进程及 MySQL 自身线程栈；若实例长期
Innodb_buffer_pool_wait_free > 0，说明 buffer pool 压力大，需扩容或优化查询减少扫描量
max_connections应基于应用连接池最大活跃数 × 1.2~1.5 设置，而非盲目堆高；同时监控
Threads_connected和
Threads_running，后者持续高于 20–30 通常意味着锁争用或慢查询堆积 避免短连接滥用：PHP-FPM 默认每请求新建连接，易触发
wait_timeout和连接创建开销；优先用长连接或连接池（如 HikariCP、mysql-router）
innodb_log_file_size影响 checkpoint 频率和 crash recovery 时间，过大延长 recovery，过小导致频繁刷盘；可参考
Innodb_os_log_written每小时增量，设为 1~2 小时写入量较稳妥
统计信息是否准确、执行计划是否稳定
MySQL 依赖表的行数、索引基数等统计信息生成执行计划。这些信息不更新，优化器可能选错索引，甚至在数据分布倾斜时彻底误判。
实操建议：
定期执行ANALYZE TABLE（尤其在大批量 INSERT/DELETE 后），或开启
innodb_stats_auto_recalc = ON（MySQL 5.6+ 默认开启） 对大表且数据倾斜严重（如 status 字段 95% 是 'done'），可手动用
OPTIMIZE TABLE重建表并更新统计信息，或用
innodb_stats_persistent_sample_pages提高采样精度 警惕执行计划漂移：同一 SQL 某天走索引，某天变全表扫描，大概率是统计信息滞后或参数（如
join_buffer_size）变化导致优化器成本估算失准；可用
USE INDEX或
FORCE INDEX临时干预，但治标不治本 升级 MySQL 版本时特别注意：8.0 的 CBO 改进较大，某些 5.7 下稳定的执行计划在 8.0 可能失效，上线前务必用生产数据集压测关键 SQL 真正卡住性能的，往往不是配置数字本身，而是索引与查询逻辑的耦合是否紧密、统计信息是否及时反映真实分布、以及慢查询是否被当成“偶发现象”放过。调参只是最后一步，前面三步漏掉任何一环，调得再细也白搭。
