MySQL Status提供服务器状态信息，是单纯的累计数（如重启就会重置），表面上只能体现多和少。但这些统计值，如zabbix，prometheus监控平台一样，通过某个时间间隔的差值，体现MySQL某种偏向的执行情况。比如临时表使用比较多，底层page交换频繁凡 等。Status统计信息是日常监控的部分核心数据，也是问题排查中非常有意义的参考数据。
mysql > SHOW [GLOBAL | SESSION] STATUS
[LIKE 'pattern' | WHERE expr]STATUS
1.执行情况
性能指标（TPS，QPS）是衡量数据库的能力的一个标准。这些指标依据也是通过Status里计算的。
QPS（Queries Per Second，每秒查询数）=Com_select
TPS（Transactions Per Second，每秒处理事务数）=Com_insert + Com_delete + Com_update
| 指标 | 说明 |
|---|---|
| Questions | 服务器收到的查询和命令的总数 |
| Com_select | 执行select语句的总数 |
| Com_insert | 执行insert语句的 |
| Com_delete | 执行delete语句的 |
| Com_update | 执行update语句的 |
2.SQL质量情况
对于mysql来说随着数据量增加 全表扫描，不使用索引，排序，回滚 这些现象对于MySQL是最致命的。大量消耗mysql处理能力，服务器资源（硬盘io，cpu资源 等）。
| 指标 | 说明 |
|---|---|
| Slow_queries | 积累的慢日志数量 |
| Select_full_join | 全表join |
| Select_full_range_join | 全表范围join |
| Select_scan | 单表全表扫描次数 |
| Sort_scan | 通过扫描表完成的排序数 |
| Com_rollback | sql语句回滚 |
| Handler_rollback | 回滚一个事务的请求的个数 |
3.临时表利用率
临时表多，说明多表join产生大量的中间表，排序无索引，聚合等。最终会趋向于语句执行越来越慢 等问题。
| 指标 | 说明 |
|---|---|
| Created_tmp_disk_tables | 临时表落盘次数 |
| Created_tmp_files | 创建临时文件次数 |
| Created_tmp_tables | 临时表使用次数 |
关注下临时表设置是否合理(tmp_table_size，max_heap_table_size）,临时表缓存 大概16M~128M既可以，如果已经非常大，说明SQL要进行优化.
4.文件表数量
说明底层ibd，frm 文件太多 或 操作系统 /etc/security/limits.conf设置太小导致
| 指标 | 说明 |
|---|---|
| open_tables | 当前mysql数据库打开的表数量 |
| open_files | mysql数据库的server层当前正打开的文件数据 |
| Table_open_cache_overflows | 表缓存溢出次数，如果大于0,可以增大table_open_cache和table_open_cache_instances |
| Innodb_num_open_files | innodb当前打开的文件数量 |
| Table_open_cache_misses | 需要先检索此表已经存在于table_cache中，如果不存在，需要新构建，需要添加table_open_cache，table_definition_cache |
需要协调的参数有5个需要按照实际情况进行调整：
- innodb_open_files
- open_files_limit
- table_open_cache
- table_open_cache_instances
- table_space_definition_cache
5.底层page相关操作
innodb引擎对于page的操作。
- 特别是Handler_read_rnd_next 对于性能影响非常大。主要体现SQL语句方面不使用索引，全表扫描情况。
- 大数据量随机读之类的。
| status | 说明 |
|---|---|
| Handler_read_first | 此选项表明SQL是在做一个全索引扫描，注意是全部，而不是部分，所以说如果存在WHERE语句，这个选项是不会变的。 |
| Handler_read_key | 此选项数值如果很高，系统高效的使用了索引，一切运转良好。 |
| Handler_read_next | 此选项表明在进行索引扫描时，按照索引从数据文件里取数据的次数。 |
| Handler_read_prev | 此选项表明在进行索引扫描时，按照索引倒序从数据文件里取数据的次数，一般就是ORDER BY … DESC |
| Handler_read_rnd_next | 此选项表明在进行数据文件扫描时，从数据文件里取数据的次数。 |
6.binlog情况
binlog是逻辑写入，一旦变更量多之后（insert，delete，update，ddl），binlog缓存刷新频率过高，影响一定的性能，带来迟缓效应。
| 指标 | 说明 |
|---|---|
| Binlog_cache_disk_use | 事务引擎因binlog缓存不足而用到临时文件的次数，如果这个值过大，可以通过增大binlog_cache_size来解决 |
| Binlog_stmt_cache_disk_use | 非事务引擎因binlog缓存不足而用到临时文件的次数，如果这个值过大，可以通过增大binlog_stmt_cache_size来解决 |
binlog_cache_size默认是32k，建议范围在1M~16M以内 ，如果超过这个值 就会使用临时表，所以MySQL不适合一些大事务。
7.线程
线程信息往往代表mysql链接情况。比如频繁的短连接可能对于mysql穷住，内存无法释放等问题。
当前执行的线程数也不能太多，会达到处理的瓶颈。
| 指标 | 说明 |
|---|---|
| Threads_cached | 线程缓存所能容纳的线程的最大个数.断开的mysql连接会放到这个缓存里,新建立的连接就会重复使用它们而不创建新的线程 |
| Threads_connected | 已连接过的线程总数 |
| Threads_created | 为处理连接创建的线程总数 |
| Threads_running | 当前执行的线程数 |
8.链接错误
当通信故障错误出现时，MySQL的状态变量Aborted_clients和Aborted_connects的计数会增加。这两个状态变量描述了链接中断，登录MySQL失败的计数。
- 客户端无权限,密码有误,连接包错误,连接时间限制，客户端没有进行关闭,突然终止 等。
- 参数timeout不合理也会出现这些值上升。（connect_timeout，wait_timeout，interactive_timeout net_read_timeout，net_write_timeout）
| 指标 | 说明 |
|---|---|
| Aborted_clients | 由于客户端未正确关闭连接而死亡而中止的连接数 |
| Aborted_connects | 连接MySQL服务器失败次数 |
9.DDL情况
经验告诉，在MySQL使用触发器，存储过程，函数等存在很多隐患。
| 指标 | 说明 |
|---|---|
| Com_create_trigger | 创建触发器 |
| Com_create_procedure | 创建存储过程 |
| Com_create_event | 创建event事件 |
| Com_create_view | 创建视图 |
| Com_create_udf | 创建自定义函数 |
| Com_call_procedure | 执行存储过程 |
| Com_load | load命令调用 |
| Com_stmt_prepare | 预处理语句 |
10.其他
| 指标 | 说明 |
|---|---|
| Uptime | 服务器最后一次启动以来的的秒数。 |
| Com_flush | 表示执行了多少FLUSH语句 |
| Last_query_cost | session会话作用域，由查询优化器计算的最后一个已编译查询的总成本 |
| Locked_connects | 连接锁定用户帐户的尝试次数 |
| Com_lock_instance | instance实例锁住次数 |
| Com_lock_tables | 锁表次数 |
| Table_locks_waited | 对表锁的请求不能立即被授予，需要等待的次数 |
| Innodb_os_log_pending_fsyncs | InnoDB重做日志中挂起的fsync()操作的次数。 |
| Innodb_os_log_pending_writes | 挂起写入InnoDB重做日志文件的次数。 |
| Innodb_data_pending_fsyncs | 当前挂起的fsync()操作数 |
总结
Status计数，不仅是监控需要的指标，也是日常排查问题的一种判断推理依据。
