索引设计需覆盖高频查询条件，重点检查WHERE、JOIN、ORDER BY、GROUP BY字段是否合理索引；联合索引遵循最左前缀原则；避免在索引列使用函数；统计信息需及时更新以保障执行计划稳定。
索引设计是否覆盖了高频查询条件
没有索引或索引失效是 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
