幸好我会观测MySQL，不然就露馅了

数据库作为业务的顶梁柱，左右着应用架构及应用性能，应用服务性能可以通过对服务本身横向伸缩来解决，但是数据库的性能决定了应用的最终命脉，MySQL 作为数据库之王，几乎运用在各行各业。随着业务增量，不规范的使用 SQL、大量慢查询会将应用拖垮，所以观测它显得尤为重要。

MySQL 监控¶

想要了解MySQL的性能与执行情况，主要从4个方面来全局查看 MySQL 相关指标信息

1. 概览
2. 活动用户信息
3. InnoDB
4. 锁信息

概览¶

概览部分主要是对 连接数、QPS、TPS、异常连接数、每秒无索引 join 查下次数、Schema 大小分布、慢查询、锁等待时长等维度对 MySQL 进行概览分析。 

图片截自“观测云”

活动用户信息¶

你关注过 MySQL connection 吗？先来看个 error

MySQL: ERROR 1040: Too many connections

我们知道 MySQL 连接允许长连接和短连接，其自身建立连接的过程存在较大开销，所以一般会采用长连接。但使用长连接后可能会占用内存增多，因为 MySQL 在执行查询过程中临时使用内存管理连接对象，这些连接对象资源只有在连接断开时才会释放。如果长连接累计很多将导致内存占用加大而被系统强制 KILL 而发生 MySQL 服务异常重启的现象。

针对长连接的这种情况需要定期断开，可以通过判断连接所占用内存大小来推测是否为持久性的长连接。另外可以在每次执行较大的操作后执行 mysql_reset_connection 来重新初始化后连接资源。

MySQL 连接通常是一个用户请求一个连接，如果请求操作长时间没有执行完毕，会造成连接堆积，并迅速消耗数据库的连接数。也就是说如果数据库中有长时间没有执行完毕的 SQL，它会一直占用着连接并不释放。而在此时应用的请求会一直不断的涌入数据库，造成数据库连接数被快速用完。

在云原生、微服务背景下，对数据库的 Connection 要求越来越高，所以 MySQL Connection 也容易成为应用的瓶颈，Too many connections会导致 MySQL 所在机器 CPU 爆满，同时也会导致应用因无法获取更多的 Connection 而使业务中断。实时监控它，可以让我们快速的找到数据库瓶颈。甚至可以找到每一个用户 Connection 相关细节，比如当前用户 Connection 数以及累计 Connection 数。