网站业务低峰期执行数据库完整性校验与修复

数据库完整性校验这件事，很多团队习惯在夜深人静时做，但如果你仔细观察业务曲线，真正的低峰期往往在凌晨以外的某些特定时段，比如工作日的午后或者重大版本发布后的空窗期。选择低峰期执行不是怕影响业务那么简单，更深层的原因是：在低并发状态下，数据库的页分裂、幽灵记录、索引碎片暴露得最彻底，这时候抓出来的问题往往是最真实的物理存储层面的损坏，而不是高并发下的事务锁等待造成的假阳性。

数据库完整性校验通常分为逻辑校验和物理校验两个层面。逻辑校验检查的是数据间的引用关系、约束条件是否成立，比如外键是否悬空、唯一约束是否被破坏。物理校验则直接扫描数据页、索引页的存储结构，检查页头尾校验和、页内偏移量、行指针等底层结构是否完整。这两类操作都会产生大量I/O，尤其是物理校验，几乎等同于一次全表扫描加全索引扫描。如果在业务高峰期执行，不仅会抢占磁盘带宽导致正常请求响应变慢，更麻烦的是，高并发写入会不断修改数据页，校验工具读到的页状态可能处于中间态，导致误报甚至校验进程自身崩溃。低峰期事务量小，数据页相对静止，校验结果更可信，修复操作也更安全。

动手之前，有几件事必须确认。第一，确认你的备份策略是有效的，而且最近一次全量备份已经完成并验证过可恢复。完整性修复过程中如果出现意外，比如修复脚本错误地删除了数据，没有备份就等于灾难。第二，检查磁盘剩余空间，物理校验和修复可能产生临时文件，某些数据库的修复命令还会原地重建表，需要的空间大约是原表大小的1.5倍到2倍。第三，通知上下游系统暂停相关数据同步任务，比如数据仓库的ETL抽取、只读副本的同步、缓存刷新作业等，避免修复过程中这些任务读到中间状态的数据并扩散出去。第四，在数据库连接层面设置一个较长的语句超时时间，因为校验和修复操作执行时间不可预测，默认的超时设置可能提前中断操作。

MySQL 最常用的存储引擎是 InnoDB，它的物理校验主要依赖 innochecksum 工具和 CHECK TABLE 语句。innochecksum 是离线工具，需要在数据库关闭或者表空间文件被独立访问时使用，适合怀疑表空间文件本身损坏的场景。在线校验则用 CHECK TABLE，但很多人不知道它有几个扩展选项。普通的 CHECK TABLE 只做基本的行格式检查和索引一致性检查，加上 EXTENDED 选项会逐行校验数据，加上 QUICK 则只扫描索引页不扫描数据页。在低峰期建议直接使用 CHECK TABLE tablename EXTENDED，虽然耗时长，但能发现更多隐蔽问题。

-- 对单表执行扩展校验
CHECK TABLE orders EXTENDED;

-- 批量生成校验语句
SELECT CONCAT('CHECK TABLE ', table_name, ' EXTENDED;') 
FROM information_schema.tables 
WHERE table_schema = 'your_database';

如果 CHECK TABLE 返回的结果中 Msg_text 不是 OK，而是出现 "Corrupt" 字样，就需要立即进入修复流程。InnoDB 表的修复没有 MyISAM 那么简单的 REPAIR TABLE 命令可用，因为 InnoDB 的设计哲学是依赖崩溃恢复机制来保证一致性，而不是事后修复。对于 InnoDB 表损坏，首选方案是利用主从复制或者备份恢复单表，如果实在没有可用副本，可以尝试使用 innodb_force_recovery 参数启动数据库，从 1 到 6 逐级尝试，数字越大强制跳过检查越多，但数据丢失风险也越大。进入强制恢复模式后，用 mysqldump 把损坏表的数据导出，再重建表导入。

PostgreSQL 在完整性校验方面提供了更细粒度的控制。它没有直接的 CHECK TABLE 命令，但可以通过设置 data_checksums 参数在数据页层面进行校验和验证。如果你的数据库在初始化时开启了 data_checksums，那么每次从磁盘读取数据页时，PostgreSQL 都会自动验证页的校验和，一旦不匹配就会报错。对于已运行的数据库，可以用 pg_verify_checksums 工具在数据库关闭状态下离线校验所有数据文件的校验和。在线校验则通常借助 pg_catcheck 这类第三方工具检查系统表的完整性，或者用 SQL 查询检查业务层面的约束违规。

-- 检查外键约束是否完整，找出悬空引用
SELECT tc.table_name, tc.constraint_name
FROM information_schema.table_constraints tc
JOIN information_schema.constraint_column_usage ccu 
  ON tc.constraint_name = ccu.constraint_name
WHERE tc.constraint_type = 'FOREIGN KEY'
AND tc.table_schema = 'public';

PostgreSQL 的修复思路和 MySQL 不同。如果发现数据页损坏，PostgreSQL 提供了 zero_damaged_pages 参数，设置为 on 后，遇到损坏页会将其内容清零并继续运行，而不是直接崩溃。这虽然会丢失损坏页上的数据，但能保住整个数据库的可用性。更精细的修复可以用 pg_resetwal 重置预写日志，但这属于极端操作，会丢失事务一致性，必须配合全量备份恢复使用。对于索引损坏，REINDEX INDEX 和 REINDEX TABLE 是最直接的修复手段，低峰期执行对业务影响最小。

SQL Server 在数据库完整性校验方面拥有最成熟的工具集，核心是 DBCC CHECKDB 命令。这个命令会检查数据库中所有对象的逻辑完整性和物理完整性，包括表、索引、视图、存储过程、文件组分配等。它的内部执行逻辑是先检查系统表，再检查每个用户表的分配结构、数据页和索引页，最后检查数据库级别的元数据。DBCC CHECKDB 执行时会对数据库打一个内部快照，基于快照进行一致性读取，因此不会阻塞正常的读写操作，但会消耗大量I/O和CPU资源，这也是为什么仍然建议在低峰期执行。

-- 完整检查当前数据库
DBCC CHECKDB WITH NO_INFOMSGS, ALL_ERRORMSGS;

-- 如果发现错误，查看具体损坏页面信息
DBCC CHECKDB WITH ESTIMATEONLY;

-- 修复数据库，注意 REPAIR_ALLOW_DATA_LOSS 会丢失数据
-- 仅在万不得已时使用，且必须提前备份
ALTER DATABASE your_db SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DBCC CHECKDB ('your_db', REPAIR_ALLOW_DATA_LOSS);
ALTER DATABASE your_db SET MULTI_USER;

SQL Server 的修复选项分三个级别：REPAIR_FAST 只修复非聚集索引等不影响数据完整性的小问题；REPAIR_REBUILD 可以重建索引、修复页分配错误，不会丢失数据；REPAIR_ALLOW_DATA_LOSS 则可能删除损坏的数据行甚至整个数据页来恢复数据库结构一致性。实际运维中，如果 DBCC CHECKDB 报错，首选方案永远是从备份恢复受损页面，SQL Server 支持页面级还原，比全库恢复精细得多。只有备份不可用时，才考虑 REPAIR_REBUILD，而 REPAIR_ALLOW_DATA_LOSS 必须经过业务方确认数据丢失范围后才能执行。

手动执行校验只适合临时排查问题，生产环境必须建立自动化机制。核心思路是利用操作系统的定时任务调度器，在业务低峰期触发校验脚本，并将结果写入监控系统。校验脚本需要处理几个关键点：捕获数据库返回的校验结果、解析错误信息、区分严重级别、触发相应告警。下面是一个 MySQL 的校验自动化脚本示例，它遍历所有表执行 CHECK TABLE，并将非 OK 结果记录到日志并发送告警。

#!/bin/bash
# MySQL 完整性校验自动化脚本
HOST="localhost"
USER="checker"
PASS="your_password"
DB="your_database"
LOG_FILE="/var/log/db_check.log"

TABLES=$(mysql -h${HOST} -u${USER} -p${PASS} -D${DB} -Bse "SHOW TABLES;")

for TABLE in $TABLES; do
    RESULT=$(mysql -h${HOST} -u${USER} -p${PASS} -D${DB} -Bse "CHECK TABLE ${TABLE} EXTENDED;")
    STATUS=$(echo "$RESULT" | awk '{print $3}')
    MSG=$(echo "$RESULT" | awk '{print $4}')
    
    if [ "$STATUS" != "OK" ]; then
        echo "[$(date)] ERROR: ${TABLE} - ${STATUS} - ${MSG}" >> $LOG_FILE
        # 在这里接入告警系统，比如发送钉钉、企业微信通知
    else
        echo "[$(date)] OK: ${TABLE}" >> $LOG_FILE
    fi
done

告警策略需要分级设计。CHECK TABLE 返回 "Table is already up to date" 或者 "OK" 属于正常状态，无需告警。返回 "Corrupt" 表示表已损坏，需要立即触发紧急告警并自动拉起应急流程。返回 "Found N deleted rows" 这类信息性消息则需要关注，但不属于紧急情况，可以汇总到日报中。对于 PostgreSQL，可以定期查询 pg_stat_database 视图中的 checksum_failures 计数器，一旦数值增长就说明有数据页校验失败，需要立即介入。

任何修复操作都有风险，尤其是涉及数据删除或重建的操作。执行修复前，必须在测试环境复现问题并验证修复方案。如果生产环境条件允许，可以先在只读副本上执行修复，确认无误后再操作主库。对于没有只读副本的场景，可以考虑用 mysqldump 或 pg_dump 先单独导出受损表的数据作为二次备份，即使修复失败也能手工恢复。修复操作本身也要分步执行，每完成一步就检查一次数据库状态，不要一次性执行多个修复命令。另外，修复完成后不能立即宣告结束，必须重新执行一次完整性校验，确认所有错误都已消除，同时跑一遍核心业务查询，验证数据在应用层面的可用性。

完整性校验不应该只是出问题后的补救手段，更应该成为常态化的预防机制。建立定期校验计划，根据数据库规模和低峰期窗口长度，可以每周或每月执行一次全量校验。对于超大规模数据库，全量校验时间可能超过低峰期窗口，这时可以采用分区校验策略，每次只校验一部分表或分区，在一个周期内轮转覆盖所有数据。同时，从硬件层面降低损坏风险也很关键，使用带ECC校验的内存、配置RAID冗余的磁盘阵列、定期检查磁盘SMART状态、确保数据库服务器使用不间断电源，这些基础措施能显著减少物理层面的数据损坏概率。应用层面也要做好防御性设计，对数据库返回的错误码进行区分处理，遇到数据完整性错误时能快速切换到降级方案或备用数据源，而不是让异常数据一路污染到用户界面。