DBCC CHECKDB这个命令，搞数据库的人应该都不陌生。但说实话，很多人对它又爱又怕。爱的是它能揪出数据损坏的隐患，怕的是它跑起来太耗资源，甚至有人遇到过跑完直接报错、数据库打不开的情况。我见过太多运维兄弟，平时不跑CHECKDB，等出了事才手忙脚乱地去查错误日志。今天咱们就聊聊，怎么用三步排查法，把数据损坏的隐患拦在门外。
第一步，你得知道什么时候该跑CHECKDB。很多人觉得每周跑一次就够了，但实际生产环境里，数据损坏往往是悄无声息的。我有个客户，他们的ERP系统每天成千上万笔交易，结果某天突然发现某张订单表的数据对不上账。一查，是磁盘坏道导致的数据页损坏。这时候才跑CHECKDB，已经晚了。其实，数据损坏有先兆——比如查询突然变慢、某些索引失效、备份报错。这些信号出现时，就该立刻跑一次CHECKDB。别等崩溃，等不起。
第二步，学会看懂CHECKDB的输出。这条命令跑完后，会生成一堆信息，很多人看一眼就关掉，或者只扫一眼“0 errors”就放心走人。但真相是，CHECKDB的输出里藏着很多关键线索。比如“Corruption detected”后面跟着的页ID和对象ID，能直接定位到具体是哪张表、哪个索引出了问题。还有“repairallowdataloss”和“repairrebuild”这两个选项，前者会删掉损坏的数据，后者只重建结构。我遇到过有人选错了修复模式，结果数据丢了，用户骂街。所以，看懂输出，比盲目修复重要得多。
第三步，制定修复策略，别一上来就动刀子。很多人遇到坏页，第一反应是跑REPAIRALLOWDATALOSS，但这是最后的手段。更稳妥的做法是：先从备份里恢复那个坏页，或者用REPAIRREBUILD尝试重建索引。如果实在不行，再考虑有损修复。而且，修复前一定要做业务影响评估——有些表的数据丢了，系统还能跑；有些主表坏了一块，整个业务就瘫了。我有个朋友，他们公司的报表库经常报错，他每次都直接跑有损修复，结果财务表少了几个月的数据，差点被开除。所以，修复前，先问自己：这个坏页，能不能从备份恢复？业务能不能接受丢数据？
说到这里，你可能会觉得，CHECKDB就是个麻烦事儿。但反过来想，它其实是数据库的“体检报告”。你见过谁生病了，还嫌体检麻烦的？生产环境里，数据就是命。跑一次CHECKDB，可能占用10%的CPU，但换来的是数据完整性的保障。我见过最夸张的例子，某电商平台的大促期间，数据量暴增，磁盘I/O飙到极限。运维兄弟提前跑了CHECKDB，发现有个表的数据页有逻辑错误，赶紧用REPAIR_REBUILD修复了。后来复盘，如果当时没修，大促当天那个表一查就报错，损失至少上百万。
不过，CHECKDB也不是万能神药。它只能发现当前数据文件里的损坏，但无法预防未来的损坏。所以，你得搭配监控一起用。比如SQL Server的错误日志，会记录I/O错误、页校验失败这些早期信号。还有Windows事件查看器里的磁盘错误，也能帮你提前预警。我有个习惯，每周一早上跑一次CHECKDB，同时检查系统日志。如果发现某块磁盘的坏道在增多，就赶紧申请换盘。这比等CHECKDB报错再处理，要主动得多。
别忘了修复后的验证。很多人跑完修复，觉得万事大吉，直接恢复业务。但修复只是第一步，后续还得确认数据是否完整、业务是否正常。比如，修复完某张表后，先跑一次SELECT COUNT(*)看行数对不对，再跑一次业务查询看结果是否一致。我遇到过修复后索引失效的情况，导致查询慢得像蜗牛，又花了两小时重建索引。所以，修复后的验证，跟修复本身一样重要。
总结一下，三步排查法其实就三个字：早、准、稳。早，是提前发现信号，别等崩溃；准，是看懂输出，定位问题；稳，是制定策略，别盲目修复。数据损坏这事儿，就像车上的故障灯，亮了就得赶紧查，别等趴窝了再后悔。下次你遇到数据库报错，别慌，先跑个CHECKDB，按这三步走，说不定就能救回一库数据。
