MySQL 8.0 数据库Server Status Variables说明

一、连接与错误处理

包含变量

• Aborted_clients：客户端异常断开的连接数
• Aborted_connects：连接失败次数
• Connections：连接尝试总次数（含成功/失败）
• Locked_connects：连接被锁账户的次数
• Max_used_connections：自启动以来最大并发连接数
• Max_used_connections_time：达到最大并发连接的时间
• Connection_errors_accept：accept() 调用错误次数
• Connection_errors_internal：内部错误导致拒绝连接的次数
• Connection_errors_max_connections：因 max_connections 满拒接次数
• Connection_errors_peer_address：查找客户端 IP 时的错误次数
• Connection_errors_select：select()/poll() 错误次数
• Connection_errors_tcpwrap：被 libwrap 拒绝的次数

运维解读与举例

这类变量直接反映数据库的连接健康度与瓶颈。

• Aborted_clients 异常升高
  通常说明客户端忘记调用 mysql_close()，或者网络超时/中断。如果达到上千，需检查应用连接池的 wait_timeout 设置，以及网络链路质量。

  场景举例：Java 应用异常重启，未正常归还连接，导致大量 Aborted_clients。同时 Aborted_connects 无变化，可定位是已建立连接的非正常关闭。

• Connection_errors_max_connections 多次出现
  意味着到达了最大连接数限制，新连接被拒绝。应检查 max_connections 是否足够，或应用是否存在连接泄漏。此值非零时往往伴随 Connections 很高。

  场景举例：促销活动流量突增，突然报 “Too many connections”，查看 Connection_errors_max_connections 突增，临时增大 max_connections 并重启，然后分析慢查询优化语句。

• Aborted_connects 一直增长
  可能是账户密码错误、网络策略（防火墙）、SSL 配置不正确等。对照 Connection_errors_peer_address 和 host_cache 排查具体客户端 IP。

  场景举例：新迁移的服务器，未更新授权表，导致监控脚本连接失败，Aborted_connects 持续增加。

• Max_used_connections 可用来判断历史峰值，辅助容量规划。

二、网络与流量

包含变量

• Bytes_received：接收的总字节数
• Bytes_sent：发送的总字节数
• Compression (已弃用)
• Compression_algorithm (8.0.18+)：当前连接使用的压缩算法
• Compression_level (8.0.18+)：压缩级别

运维解读与举例

• Bytes_sent/Bytes_received 可以结合 Uptime 计算平均带宽使用，判断是否需要扩容网卡或检查异常大结果集的查询。

  场景举例：数据库出口带宽突然跑满，发现 Bytes_sent 短时间增长极快，配合慢查询日志发现某个 BI 查询返回了上千万行数据。优化后带宽降为原来 1/10。

• Compression_algorithm 可验证连接是否启用了压缩，以及具体算法。在带宽受限的云环境下，启用压缩可显著降低流量，但会增加 CPU 开销。

三、认证与安全

包含变量

• Authentication_ldap_sasl_supported_methods (8.0.21)
• Caching_sha2_password_rsa_public_key
• Rsa_public_key

运维解读与举例

这些变量主要用于确认认证插件所支持的方法以及密钥是否正确加载。若变量值为空或不符合预期，表明服务器未成功加载证书或私钥文件，用户登录会失败或降级为不安全连接。

场景举例：配置 caching_sha2_password 使用 RSA 加密，但 Caching_sha2_password_rsa_public_key 为空，客户端 SSL 连接错误，检查发现 caching_sha2_password_public_key_path 指向的文件不存在。

四、二进制日志缓存

包含变量

• Binlog_cache_disk_use：事务因超缓存而写临时文件的次数
• Binlog_cache_use：使用 binlog 缓存的事务次数
• Binlog_stmt_cache_disk_use：非事务语句写临时文件次数
• Binlog_stmt_cache_use：使用 binlog 语句缓存的次数

运维解读与举例

• Binlog_cache_disk_use 过多 表明 binlog_cache_size 太小，事务被迫写磁盘临时文件，会增加 I/O，影响事务提交性能。

  场景举例：大事务（单条 SQL 更新大量行）提交时发现磁盘 IO 飙高，查看 Binlog_cache_disk_use 显著大于 Binlog_cache_use，增大 binlog_cache_size 后缓解。

• 对于非事务引擎（如 MyISAM），同样要关注 Binlog_stmt_cache_disk_use 与 binlog_stmt_cache_size 的比例。

五、命令执行统计

包含变量

• Com_xxx 系列（如 Com_select, Com_insert, Com_update, Com_delete 等）
• Com_stmt_prepare, Com_stmt_execute 等预编译语句统计
• Com_change_repl_filter, Com_explain_other 等特殊命令

运维解读与举例

这些计数器记录每种语句类型的执行次数，可通过差值计算每秒查询数（QPS）或各类操作的比例，帮助了解数据库负载特性。

场景举例：数据库 CPU 突然高，监控发现 Com_select 增长平稳，但 Com_update 和 Com_delete 骤升，定位到定时大清理任务正在运行，对该任务进行限流。

Com_stmt_reprepare 表示语句被隐式重新编译的次数，过高可能意味着频繁的元数据变更（如表结构更改），可能带来开销。

六、临时表与文件

包含变量

• Created_tmp_disk_tables：磁盘临时表数量
• Created_tmp_tables：临时表总数（内存+磁盘）
• Created_tmp_files：mysqld 创建的临时文件数量

运维解读与举例

• 磁盘临时表比例过高 (Created_tmp_disk_tables / Created_tmp_tables) 说明很多查询的临时表超出了 tmp_table_size 或 max_heap_table_size，被迫写入磁盘，会严重影响查询速度。

  场景举例：慢查询日志中大量 Creating sort index 或 Copying to tmp table on disk，观察 Created_tmp_disk_tables 快速增长。优化 SQL（添加索引、避免 SELECT *、减少 ORDER BY 非索引列）后比例降低。

• Created_tmp_files 偏高可关联到 binlog 临时文件或 LOAD DATA 操作。

七、表定义与文件打开缓存

包含变量

• Open_files：当前打开的文件数
• Opened_files：累计打开的文件数（通过 my_open()）
• Open_table_definitions：缓存的表定义数
• Opened_table_definitions：累计缓存的表定义数
• Open_tables：当前打开的表数
• Opened_tables：累计打开的表数
• Table_open_cache_hits：表缓存命中次数
• Table_open_cache_misses：表缓存未命中次数
• Table_open_cache_overflows：表缓存溢出次数

运维解读与举例

• Opened_tables 增长过快 说明大量表被反复打开关闭，table_open_cache 可能太小。计算缓存命中率 = Table_open_cache_hits / (Table_open_cache_hits + Table_open_cache_misses)，若低于 99% 考虑增大缓存。

  场景举例：分库分表场景下，几百个表频繁访问，Opened_tables 每秒增加几十，操作系统文件描述符消耗快。调大 table_open_cache，重启后观察 Open_tables 上限。

• Open_files 接近 open_files_limit 时应降低 table_open_cache 或增加系统限制，否则会导致无法打开新文件。

• Table_open_cache_overflows 不为零表示缓存满时有表被踢出，可适当增大缓存或调大 table_open_cache_instances。

八、MyISAM 键缓存（适用于仍在使用 MyISAM 的情况）

包含变量

• Key_blocks_not_flushed, Key_blocks_unused, Key_blocks_used
• Key_read_requests, Key_reads
• Key_write_requests, Key_writes

运维解读与举例

• 键缓存命中率 = Key_reads / Key_read_requests。若该值 > 0.01（即 1%），说明有较多物理读，可增大 key_buffer_size。

  场景举例：历史遗留的 MyISAM 表查询变慢，发现 Key_reads 上百万，而 Key_read_requests 只有几千万，计算命中率低于 90%，加大键缓存后性能提升。

九、InnoDB 缓冲池

包含变量

• Innodb_buffer_pool_pages_total/data/free/dirty/misc 等
• Innodb_buffer_pool_read_requests（逻辑读）
• Innodb_buffer_pool_reads（物理读）
• Innodb_buffer_pool_read_ahead 等预读相关
• Innodb_buffer_pool_wait_free
• Innodb_buffer_pool_resize_status 等

运维解读与举例

• 缓冲池命中率 = (Innodb_buffer_pool_read_requests - Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests。应保持在 95% 以上。如果 Innodb_buffer_pool_reads 较高，说明热点数据无法全部缓存在内存中，需增大 innodb_buffer_pool_size。

  场景举例：新业务上线，数据量快速增长，Innodb_buffer_pool_reads 急剧上升，命中率跌破 90%，IO 压力陡增。扩大缓冲池至物理内存的 70% 后恢复。

• Innodb_buffer_pool_wait_free 非零表示等待干净页，若频繁出现，通常也需增大缓冲池。

• 页面刷新相关变量如 Innodb_buffer_pool_pages_flushed、脏页比例，可辅助调优刷新策略。

十、InnoDB 数据 I/O 与日志

包含变量

• Innodb_data_reads/writes, Innodb_data_read/written
• Innodb_data_fsyncs, Innodb_data_pending_fsyncs/reads/writes
• Innodb_log_waits, Innodb_log_write_requests, Innodb_log_writes
• Innodb_os_log_fsyncs 等
• 重做日志新变量 (8.0.30)：Innodb_redo_log_capacity_resized, checkpoint_lsn, current_lsn, logical_size, physical_size 等

运维解读与举例

• Innodb_data_pending_writes 持久 >0 说明磁盘写入跟不上，需检查 I/O 子系统或增加写入线程。

• Innodb_log_waits 增长 表示日志缓冲区 (innodb_log_buffer_size) 过小，事务提交时被迫等待，会导致 TPS 下降。

  场景举例：批量插入时 Innodb_log_waits 从 0 瞬间到几千，增大日志缓冲区到 256MB，同时配合使用组提交优化。

• 重做日志容量与使用 (8.0.30+)：Innodb_redo_log_logical_size 增长过快说明产生脏页过多；若 physical_size 显著低于容量，可能不需要太多日志文件；可通过容量调整监控 Innodb_redo_log_resize_status。

十一、InnoDB 行锁与行操作

包含变量

• Innodb_row_lock_current_waits, Innodb_row_lock_waits, Innodb_row_lock_time, avg, max
• Innodb_rows_inserted/updated/deleted/read

运维解读与举例

• 行锁等待突增：Innodb_row_lock_waits 短时间内暴增，配合 Innodb_row_lock_time_avg 超过几百毫秒，可判断存在严重的行锁竞争。

  场景举例：秒杀活动，更新同一行库存记录，出现大量锁等待，Innodb_row_lock_current_waits 居高不下，通过业务拆分、排队或引入 Redis 缓解。

• 行操作计数器 可计算每秒读写比例，帮助了解负载模型。

十二、查询与排序统计

包含变量

• Select_full_join, Select_full_range_join, Select_range, Select_range_check, Select_scan
• Sort_merge_passes, Sort_range, Sort_rows, Sort_scan
• Last_query_cost, Last_query_partial_plans

运维解读与举例

• 大量 Select_scan 和 Select_full_join：说明没有用到索引的全表扫描和全连接扫描频繁发生，这是性能杀手。

  场景举例：新上线的报表 SQL，每次执行 Select_full_join 都增加，Slow_queries 同步升高，发现缺失联合索引，添加后 Select_full_join 停止增长。

• Sort_merge_passes 过高：排序缓冲区不足，需要多次归并，增加磁盘 I/O。可通过增大 sort_buffer_size 缓解，但注意该变量是会话级，过大可能撑满内存。

  场景举例：执行大批量 ORDER BY 导出时，Sort_merge_passes 持续累积，调大 sort_buffer_size 到 4MB 后归并次数下降。

• Last_query_cost：可以用来对比同一查询不同写法或不同索引的优化器代价，辅助调优。

十三、表锁与表缓存性能

包含变量

• Table_locks_immediate：立即获取表锁的次数
• Table_locks_waited：等待表锁的次数

运维解读与举例

• 表锁等待率 = Table_locks_waited / (Table_locks_immediate+Table_locks_waited)。若较高（如 > 5%），说明 MyISAM 或其他非 InnoDB 引擎的表锁竞争严重，或者 InnoDB 在某些操作（如 DDL）时仍会使用元数据锁。

  场景举例：某个 MyISAM 表同时有大量读写，Table_locks_waited 极高，改为 InnoDB 后等待消失。

十四、线程与连接管理

包含变量

• Threads_connected, Threads_running, Threads_cached, Threads_created
• Slow_launch_threads

运维解读与举例

• 线程创建频率过高 (Threads_created/Connections)：说明线程缓存命中率低，应加大 thread_cache_size。

  场景举例：短连接应用频繁建立断开连接，Threads_created 每秒增加几十，CPU 系统消耗偏高，增大 thread_cache_size 后 Threads_cached 保留更多线程，创建速率下降。

• Threads_running 持续接近 CPU 核数 可能表明查询堆积，需检查是否有长时间运行的 SQL 或锁等待。

十五、慢查询与执行超时

包含变量

• Slow_queries
• Max_execution_time_exceeded, Max_execution_time_set, Max_execution_time_set_failed

运维解读与举例

• Slow_queries 趋势：即使未开启慢查询日志，该变量也会增长，结合监控可发现异常。
• Max_execution_time_exceeded 表示有查询执行超过了 max_execution_time 或 MAX_EXECUTION_TIME 提示而超时结束，可用于保护系统资源。

  场景举例：配置了 max_execution_time=5000，有时 BI 查询运行超过 5 秒被自动杀掉，Max_execution_time_exceeded 增加，从而避免某个查询长期占用资源。

十六、SSL/TLS 状态

包含变量

• Ssl_accepts, Ssl_finished_accepts, Ssl_cipher, Ssl_version, Ssl_server_not_after 等
• Current_tls_ca, Current_tls_cert 等 (8.0.16+)
• Tls_library_version (8.0.30)

运维解读与举例

• 验证 SSL 是否启用：Ssl_accepts 大于 0，Ssl_cipher 非空。
• 证书有效期：Ssl_server_not_before 和 Ssl_server_not_after 直接显示证书有效时间，可用于告警提前续期。

  场景举例：生产库突然无法连接，发现 SSL 证书过期，Ssl_server_not_after 已过去。建立监控，提前告警。

十七、复制与半同步

包含变量

• 半同步复制系列：Rpl_semi_sync_source_clients, status, tx_waits, no_tx 等
• 复制临时表：Replica_open_temp_tables (8.0.26+)
• 行定位算法：Replica_rows_last_search_algorithm_used (调试)
• GTID 相关：Ongoing_anonymous_transaction_count 等

运维解读与举例

• 半同步复制降级：Rpl_semi_sync_source_status 从 ON 变为 OFF，同时 Rpl_semi_sync_source_no_tx 增加，表示等待副本确认超时，退回异步复制。检查网络或副本性能。
• 临时表积压：Replica_open_temp_tables > 0 时，不建议停止复制或重启副本，应等待处理完。
• GTID 一致性违反 (调试版本)：若使用 GTID 并看到 Ongoing_anonymous_gtid_violating_transaction_count 非零，说明有匿名事务写入，可能导致主从不一致，应避免。

十八、其他重要杂项

• Prepared_stmt_count：当前预编译语句数，超过 max_prepared_stmt_count 会报错。
• Queries 与 Questions：Queries 包含存储过程内部语句，Questions 仅客户端直接 SQL。评估 QPS 时依据 Questions 更贴近应用负载。
• Uptime 与 Uptime_since_flush_status：计算速率的基础时间。
• Resource_group_supported：确定是否可以限制资源组。
• Tc_log_page_waits：若过高，考虑增大 --log-tc-size（通常对二进制日志恢复无影响）。
• Global_connection_memory (8.0.28)：若启用跟踪，可监控所有连接内存总量，防止 OOM。

运维学习要点总结

1. 将状态变量与业务现象关联：例如锁等待升高 → 出现大量 update 冲突。
2. 使用差值计算速率：结合 Uptime 或监控系统算 QPS、每秒逻辑读、每秒创建临时表等。
3. 关注比例而非绝对值：比如缓冲池命中率、临时表磁盘化比例、表锁等待率，比单纯的次数更有意义。
4. 版本变化：注意 8.0.18 的压缩变量、8.0.22 的错误日志统计、8.0.30 的重做日志增强等，文档随时更新。
5. 从全局到会话：部分变量有 GLOBAL 和 SESSION 作用域，诊断当前会话问题时用 SHOW SESSION STATUS。

希望这份解读能帮助你快速上手 MySQL 8.0 的状态监控与故障诊断。