MySQL性能调优需重点关注连接、查询、缓存、IO四类核心指标：Threads_connected和Threads_running反映并发负载；Slow_queries与Handler_read_*揭示SQL效率问题；Innodb_buffer_pool_read_hits等衡量缓存命中率；Innodb_log_waits和Innodb_row_lock_waits暴露IO与锁瓶颈。

MySQL性能调优离不开对关键运行指标的持续观察和分析。这些指标不是孤立的数字，而是反映数据库真实负载、资源瓶颈和SQL执行效率的“健康信号”。重点关注以下四类核心指标，它们覆盖连接、查询、缓存和IO层面，能快速定位大多数常见性能问题。

连接与并发相关指标

这类指标体现客户端连接状态和服务器承载能力，直接影响服务可用性。

• Threads_connected：当前活跃连接数。长期高于应用配置的最大连接池（如Spring Boot的max-active）可能说明连接未释放或泄漏；突增伴随响应延迟，需检查慢查询或长事务阻塞。
• Threads_running：真正正在执行的线程数（非睡眠态）。若持续接近或超过CPU核心数，说明并发压力大，可能触发排队等待；配合SHOW PROCESSLIST可识别是否被锁或卡在IO上。
• Aborted_connects / Aborted_clients：异常断开连接次数。值升高常指向网络不稳定、认证失败（如密码错误）、或客户端超时设置过短，而非数据库本身故障。

查询执行与响应效率指标

直接关联用户体验，是调优最常切入的维度。

• Queries / Questions：每秒总SQL请求数。结合Com_select/insert/update/delete细分类型，可判断读写比例是否失衡（如高写入+低缓冲易引发刷脏页压力）。
• Slow_queries：慢查询累计数（需先开启slow_query_log=ON并设long_query_time）。不只看数量，更要查mysqldumpslow或慢日志解析工具输出的TOP SQL，聚焦“平均耗时高”或“扫描行数远大于返回行数”的语句。
• Handler_read_*（如Handler_read_next, Handler_read_rnd_next）：反映存储引擎层数据读取方式。若Handler_read_rnd_next占比高，说明大量全表扫描后排序，通常意味着缺少合适索引或ORDER BY无法利用索引。

缓冲与缓存命中率指标

内存利用效率高低，决定磁盘IO压力大小。

• Key_buffer_read_requests / Key_buffer_read_hits（MyISAM）或Innodb_buffer_pool_read_requests / Innodb_buffer_pool_read_hits（InnoDB）：计算缓存命中率（如1 - (reads / read_requests)）。InnoDB建议保持在95%以上；低于90%需优先考虑增大innodb_buffer_pool_size（通常设为物理内存的50%–75%）。
• Qcache_hits / Qcache_inserts（若启用查询缓存）：命中率低于50%且Qcache_lowmem_prunes频繁增长，说明缓存碎片严重或淘汰过快，此时关闭查询缓存反而更稳定（MySQL 8.0已移除）。

IO与刷新行为指标

磁盘操作是主要性能瓶颈来源，尤其在高写入场景。

• Innodb_data_reads / Innodb_data_writes：每秒物理读写次数。突增需结合Innodb_buffer_pool_wait_free判断是否因缓冲池不足导致强制刷盘。
• Innodb_log_waits：重做日志空间不足导致的等待次数。非零值说明innodb_log_file_size过小或写入峰值过高，应增大日志文件并确保innodb_log_files_in_group × innodb_log_file_size ≥ 1GB。
• Innodb_row_lock_waits：行锁等待次数。持续增长需检查是否存在热点行更新（如计数器字段）、长事务未提交，或缺少唯一索引导致锁范围扩大。

监控这些指标不需要复杂工具，SHOW GLOBAL STATUS配合定时采集即可。关键是建立基线（业务低峰期的正常值），再对比异常时段的变化幅度——比绝对数值更有诊断价值。不复杂但容易忽略。