【文章转载于https://cloud.tencent.com/developer/article/2390515】
数据库巡检
基于时间纬度数据库巡检可以分为
日常巡检，基于我们积累的运维经验和故障经验，形成数据库层的监控，比如主键溢出， 备份有效性验证，配置参数和内存中运行的参数是否一致， 主备参数是否一致等等
节前巡检，主要是应对各种长假，比如 五一，十一，春节等较长时间的假期，因为假期时间长，相关人员响应时间可能比较长，因此需要重点检查数据库空间增长情况，大表增长，日常存储空间等，避免假期时间长， 空间不足等需要扩容资源时，各方响应比较慢的情况。
基于操作方式，可以分为
手动巡检 (实例数比较少的情况下，通过手动命令执行相关检查)
工具巡检 使用开源或者自研工具辅助查看 实例的运行状态，收集相关数据，并做出判断。
平台巡检 (应对大规模实例比如数百，数千个实例) 能全访问收集实例运行状态数据，并根据阈值报警或者给出相关问题，风险的处理动作。
巡检内容
数据库层面
1.自增主键增速是否异常，int类型 70%， bigint 182亿亿，理论上 不会有啥问题，但是挡不住有可爱的开发同学手动写入一个非常大的值，造成bigint 自增主键溢出的风险。
2.大表，比如日志类型的表，经常删除的表空洞 ，是否要提前处理碎片
3.备份有效性验证， 有条件的可以对所有数据库 ，或者核心业务的数据库进行备份恢复验证，恢复好之后，查询其中的表
4.备份服务器的空间问题，备份存放空间增量会不会满？
5.数据库实例，尤其是日志流水型，账务，交易， 日志类的系统占用的空间增量在假期间是否会有暴涨的风险。需要提前归档数据，迁移实例。避免节假日产生不必要的变更。
6.主备库参数是否一致， 避免不一致造成异常切换之后出现意外情况，
7.实例运行时参数 和 my.cnf 参数文件中值是否一致，异常重启之后，部分运维时设置的参数改变导致非一致性预期，可能造成其他故障。
8.其实还有一个是统计信息，主备的统计信息是否一致，数据库切换之后 会带来不一样的执行计划，导致潜在的性能风险。
数据库生态相关机器
1.运维平台应用所在的机器的稳定性
2.高可用组件的机器 orch，mha，或者各个公司自研产品。
3.数据库实例的元数据库问题,这里云数据库的面临的问题会更大，类似监控的监控，要确保核心的元数据库运行时稳定。
4.平台定时调度任务组件，比如 celery
主机层面
1.CPU 负载
2.CPU 工作模式，最大性能？还是最省电模式，不同模式会带来不同的CPU 主频，进而影响 SQL 执行效率。
3.内存 是否使用过的 70% ？SWAP 参数是多少，各个机器上的值否统一？
4.RAID 卡充放电问题，RAID 充电会到账 IO 策略降级为 WT 模式，造成性能问题，产生大量慢查询。
5.核心数据盘空间 是否足够， 这点和 数据库层的第5点类似。