mysql性能调优主要关注哪些方面_mysql性能优化核心点解析_网络技术

索引设计需覆盖高频查询条件，重点检查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) = 2025 会导致索引失效，应改写为 WHERE create_time >= '2025-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 的结果未必等于真实执行路径

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

真正卡住性能的，往往不是配置数字本身，而是索引与查询逻辑的耦合是否紧密、统计信息是否及时反映真实分布、以及慢查询是否被当成“偶发现象”放过。调参只是最后一步，前面三步漏掉任何一环，调得再细也白搭。