概述

mysql数据库的健康检查一般会涉及索引设计、容量规划、服务安全、参数配置、用户访问、集群复制6个方面。下面对这6个方面来做下介绍。

一、索引设计

合理的索引设计能够有效加速数据库的访问，提高查询的执行效率，减少用户查询对服务端的资源消耗。但是不合理的、低效的、冗余的甚至无效的索引不仅无法起到加速查询的效果，反而会影响数据库的插入、更新性能，甚至是数据库的高可用方案能否生效。

1、主键索引缺失

由于MySQL默认存储引擎InnoDB（MySQL 5.6版本 以上）使用的是聚簇索引表设计，这就要求所有的表必须包含一个主键，所有的数据记录按照主键次序构建B+树。如果用户在创建表时显式指定主键，则数据库会使用用户指定的主键构建B+树，但是如果用户没有显式指定主键，同时也没有创建任何唯一键索引，InnoDB为了确保每张表至少包含一个主键，则默认会为用户生成一个“隐含主键”，该主键对用户不可见，甚至对于MySQL Server层的binlog也不可见。binlog是连接MySQL主从复制节点的纽带，所有主节点的更新都是通过binlog传递给从节点的，一旦binlog中没有更新记录的主键ID，这就会导致基于Row格式的binlog在从节点执行时，无法唯一确定一条记录，只能通过全表扫描来进行匹配，大幅降低了从机的执行效率，造成复制延迟。如果是高可用故障切换的从节点，会导致切换的时间大幅增加，甚至会导致高可用机制失效。如果是实现读写分离的只读从节点，则会导致应用读到的数据可能是很久以前的旧数据。建议使用InnoDB存储引擎的MySQL用户在创建表时，必须显式指定主键。

2、主键索引业务相关

如果用户在创建表时指定的主键与业务相关，可能会被频繁的更新，这样会引起MySQL数据库的InnoDB存储引擎进行频繁的节点合并和分裂，造成大量额外的系统IO开销，影响数据库的插入和更新性能。推荐开发者在创建表时指定与业务无关的自增字段作为主键，这样不仅会提高按时间序插入的性能（顺序写入硬盘），同时也可以提高按插入时间范围检索的查询效率。

3、冗余索引

如果一个索引涉及的字段属性包含另外一个索引涉及的字段属性，同时两个索引字段顺序一致，且两个索引的首字段属性相同，则可以认为涉及字段少的索引为冗余索引。在MySQL 5.7推出sys库之前，我们可以通过percona的工具pt-duplicate-key-checker来完成对冗余索引的检查，在MySQL 5.7中，我们可以通过sys库schema_redundant_indexes表来完成。

4、低效索引

索引的作用在于通过索引，查询能够扫描更少的记录。数据库中的记录在索引字段区分度越高，扫描的记录数就越少，执行的效率就越高。如果数据库表中的记录在索引字段区分度不大，索引对记录的筛选结果就不明显，索引就无法起到加速查询的作用。通过数据库记录在索引字段的区分度，我们可以衡量索引的执行效率。

MySQL系统库mysql库下，innodb_index_stats表的stat_value字段，记录了某张表在某个索引的不同取值的记录个数，innodb_table_stats表的n_rows字段记录了某张表的总记录数，二者相除，即可得到数据库记录在某个索引的区分度，越接近1，表示区分度越高，低于0.1，则说明区分度较差，开发者应该重新评估SQL语句涉及的字段，选择区分度高的多个字段创建索引，通过运行下面的SQL语句，就可以计算每张表的索引区分度。

SELECT i.database_name AS db, i.table_name AS table, i.index_name AS index_name, i.stat_description AS cols, i.stat_value AS defferRows, t.n_rows ASROWS, ROUND(((i.stat_value / IFNULL(IF(t.n_rows <i.stat_value,i.stat_value,t.n_rows),0.01))),2) AS sel_persent FROM mysql.innodb_index_stats i INNER JOIN mysql.innodb_table_stats t ON i.database_name = t.database_name AND i.table_name= t.table_name WHERE i.index_name != 'PRIMARY' AND i.stat_name LIKE '%n_diff_pfx%'; 

也可以在这个WHERE条件后面跟上t.database_name=’库名’ AND t.table_name=’表名’用于精确查找某个表的索引区分度。

5、无效索引

如果一个索引始终无法被查询使用，它的存在只能增加数据库的维护开销，开发者应该及时删除这些索引。通过MySQL 5.7 sys库schema_unused_indexes视图，可以查看当前实例哪些索引从没有被使用。

二、容量规划

1、cpu

通常使用CPU利用率衡量CPU的繁忙程度，通过top命令，开发者可以查看CPU利用率实时变化。CPU 利用率持续超过80%，预示计算资源已经接近饱和，如果开发者已经做过SQL优化，则需要使用更高配置的CPU。通过查看7天内CPU利用率超过80%的时间占整体时间的百分比，以及单次持续时间超过一定阈值，则可视为CPU扩容的触发条件。

2、IO

大部分数据库应用都是的IO Bound类型，IO 处理能力直接决定了数据库的性能。IO 利用率统计了一秒内IO请求队列非空的时间比例，IO利用率越高就表示硬盘越繁忙。但是IO 利用率100%并不表示系统已经无法处理更多的IO请求。IOPS和每秒IO字节数可以从存储设备的层次更准确的描述IO负载。每一个存储设备都有IOPS和每秒IO字节数的上限，任意一个达到上限，就会成为IO处理能力的瓶颈，在传统机械硬盘中，随机IO主要受到IOPS的限制，顺序IO主要受带宽限制。除此之外，我们还可以从应用的角度，使用一次IO请求的响应时间来描述IO负载，一次IO请求的响应时间包括其在队列中的等待时间和实际IO处理时间之和。通过iostats开发者可以很方便的收集这些数据。如果这些指标在一段时间内持续接近设定上限，则可以认为IO 过载，通过扩大内存，让更多的读写请求命中缓存可以缓解硬盘IO。另外，使用更高配置的存储设备，例如固态硬盘，也可以大幅提高系统的IO处理能力。

3、存储空间

存储空间不足会导致严重的系统故障，数据库可能会宕机，更为严重的是数据库进程存活，但是无法响应服务，从而造成基于进程的宕机监控失效。根据7天内数据库中存储数据的变化，我们可以按照一定的拟合算法，估算出未来3天内数据的增长情况，来判断实例是否存在存储空间不足的风险。

4、内存

使用InnoDB存储引擎的MySQL数据库在实例启动时，就会预分配一块固定大小的内存空间，所有读写请求都会在该空间中完成，如果内存中缓存了用户读写的数据，则直接读取内存，如果内存中没有用户读写的数据，则需要将数据先从硬盘中load进内存中，由于内存的读写速度远远快于硬盘，这就使得读写请求是否命中内存决定了读写请求的处理速度。内存空间越大，缓存数据越多，命中的几率也就越大。所以我们可以使用缓存命中率来衡量内存空间大小是否满足应用的需求。在MySQL中，show engine innodb status 命令的Buffer pool hit rate可以度量近一段时间范围内Buffer pool的命中情况。

5、网络

网络带宽在数据库返回记录较多的情况下，也可能会成为系统的瓶颈。一般我们使用每秒网络流入和流出字节数来衡量网络流量是否达到带宽限制。在云环境下，每台虚拟机或者容器都是有一定的网络带宽配额，私有网络的配额相对比较大，公网配额与用户付费相关；使用iftop 可以查看当前系统的网络流量。

三、服务安全

1、弱口令

MySQL的登陆认证使用的是IP和账户密码的方式，很多开发者为了方便记忆，习惯将数据库密码设置为弱密码，这实际是非常危险的。数据库中的数据很多涉及敏感业务，弱密码非常容易被破解，对数据库中的数据是一个严重安全隐患。MySQL系统库mysql库下的user表的password字段保存了所有用户的密码，MySQL使用的是两次sha-1的不可逆加密算法，所以我们无法通过password字段获取用户的密码内容，但是我们可以通过将常见弱密码制成彩虹表，模拟MySQL的加密算法，匹配password字段，即可发现数据库中的弱密码账号。

2、网络安全

在一般的业务架构中，数据库都不会直接服务于终端用户，而是服务于运行业务逻辑的应用程序。所以数据库和业务程序之间出于安全的考虑，会选择使用私有网络。即便如此，为了避免数据库连错，也需要在设置数据库账号时，增加IP来源限制。在一些特定的场景下，如果数据访问必须借助公网来实现，就会将数据库暴漏在公网上。使用公网数据库实例，必须要配置防火墙，否则存在被攻击的隐患。通过iptables我们可以控制访问数据库的来源IP。

3、权限检查

MySQL提供了多种权限配置，为了方便管理以及避免误操作，一般会将管理权限和访问权限配置成两个不同的账号，禁止使用管理权限作为业务程序访问数据库的账号。通过系统库mysql库的user表可以确认各个账号拥有的权限，尽量避免业务账号拥有super权限。

四、参数配置

1、内存相关参数

MySQL数据库的内存使用包括两个部分：共享内存与连接独占内存。每一个用户新建连接，数据库都要分配一块固定大小的内存空间保存用户的临时数据，这些空间为单个连接独占。在MySQL实例启动时，系统同时也会预先分配一些实例级别的共享内存空间，例如Innodb_buffer_pool，Innodb_log_buffer_pool等，供所有连接共享。独占内存空间乘以最大连接数加上共享内存空间，我们可以计算出MySQL最大可使用的内存空间，如果超过实际物理内存大小，就存在MySQL进程被Linux操作系统强行oom kill风险，导致实例宕机。MySQL的这些内存空间都可以通过配置参数指定大小，如果超过实际内存空间，应该调整相应参数配置，最常见的是调整Innodb_buffer_pool和最大连接数。

2、频繁卡顿

如果设置过大，会导致数据库实例重启或者故障恢复花费大量的时间。一般，对于使用固态硬盘等高配置的存储设备的数据库，可以将重做日志设置大一些，对于使用机械硬盘的数据库，应该设置小一些，一般在512M到4G之间。innodb_flush_log_at_trx_commit定义了重做日志的刷新节奏，如果该参数非1，会导致数据库宕机重启后丢失部分更新数据，对于数据可靠性要求较高的应用造成严重影响。

3、二进制日志相关参数

binlog 主要用于MySQL集群复制以及故障恢复担任协调者的作用。binlog_format定义了binlog的格式，主要包括ROW、STATEMENT、MIXED三种格式，ROW格式是最安全的一种日志格式，会保证主从数据的严格一致，建议开发者选用ROW格式。但是ROW格式的binlog会占用更多的存储空间，通过expire_logs_days可以控制保存binlog的天数，如果binlog占用的存储空间比例超过50%，则应考虑适当减少binlog的保存天数。sync_binlog 参数定义了binlog刷新硬盘的节奏，如果非1，会导致宕机重启后最近的更新数据丢失。

4、连接数相关参数

MySQL有最大连接数限制max_connections，如果应用连接超过max_connetions限制，则会得到out of max connections异常，无法建立连接。show processlist可以查看当前的连接数，如果接近最大限制，则存在无法新建连接的风险。通过在应用端使用连接池可以控制数据库的连接数。

五、用户访问

1、慢连接

慢查询数量是最直观的反映数据库处理能力是否满足业务需求的指标。通过设置slow_query_log可以开启慢查询日志，MySQL数据库会将执行时间超过long_query_time的查询记入慢查询日志，如果某个时间段内，慢查询数量急剧增加，则开发者就必须要关注数据库的性能问题，首先就需要进行SQL优化，其次考虑资源是否需要扩容，最后可能需要数据库水平扩展方案，包括创建只读从节点。

2、死锁数量

两个事务涉及的数据库记录有重叠，如果SQL语句的加锁顺序不一致，就会导致事务之间的死锁。虽然MySQL数据库会自动的检测死锁并强制回滚系统认为代价较小的事务，但是死锁的检测与事务回滚都有较大的代价，会严重拖慢数据库的性能，所以当系统中出现大量死锁时，开发者必须引起重视，要分析发生死锁的事务的SQL语句的加锁规则，调整SQL语句。通过show engin innodb status可以查看死锁的相关信息以及系统的处理过程。

六、集群复制

1、数据安全

复制是MySQL多个节点之间实现数据同步的重要机制，主要用于搭建高可用实例主从节点以及提供多个只读从节点提高读扩展能力。节点之间的数据是否最终一致对于高可用方案是否生效，只读实例读取的数据是否正确有着严重影响。

从机执行show slave status可以获取从机的复制状态，Slave_IO_Running和Slave_SQL_Running分别表示IO和SQL线程是否正常运行，如果不正常，则应及时处理。参数relay_log_recovery和relay_log_info_repository影响从节点宕机重启后，与主机的复制位置是否正确，如果位置错误，则可能导致数据错误。

2、复制性能

复制延迟经常用来评估复制性能是否满足业务需求。Show slave status的Seconds behind master字段标识了从机落后主机的延迟时间。如果延迟较长，则会影响高可用实例主从切换的时间以及只读从节点是否能够及时读到最新数据。通过使用并行复制技术可以提高从节点的复制性能。

MySQL 5.6提供了基于Database级别的并行复制，通过slave_parallel_workers 设置并行线程数；MySQL 5.7提供了基于LOGICAL_CLOCK的并行复制， 主机上同一个Group提交的binlog中包含事务在从机并行执行，相比database，具备更高的并发性，除了设置slave_parallel_workers，还需要将slave-parallel-type设置为LOGICAL_CLOCK。slave_preserve_commit_order=1可以确保从机并行执行的事务按序提交。同时从机的log_bin和log_slave_updates参数必须同时开启。

后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注下！