结论是：不要一上来就用repair_allow_data_loss，它会直接剔除损坏页及整行数据而非修复；应优先通过emergency模式捞取原始数据，再尝试repair_rebuild重建索引，仅在万不得已时才启用repair_allow_data_loss。
直接说结论：不要一上来就用 REPAIR_ALLOW_DATA_LOSS，它大概率会删掉你刚改坏的那页上的整行数据——而你真正需要的，只是让那一页“看起来正常”，好把数据捞出来。
为什么 DBCC CHECKDB 修复后数据反而没了
很多人在手动用 DBCC WRITEPAGE 破坏页（比如改了页头或某字段值）后运行 DBCC CHECKDB('db', REPAIR_ALLOW_DATA_LOSS)，结果发现整条记录不见了。这不是命令出错，而是它的设计逻辑：当页校验和失效、B树链断裂或键值不一致时，SQL Server 会判定“这页不可信”，直接从索引中剔除该页及其所有行，而不是尝试恢复原始内容。
换句话说：REPAIR_ALLOW_DATA_LOSS 不是“修复页”，而是“绕过损坏页”。它解决的是数据库结构一致性问题，不是数据内容还原问题。
- 页头被改（如 m_type、m_pageid 字段）→ 触发 824 错误 →
REPAIR_ALLOW_DATA_LOSS可能丢整页 - 页内某字段二进制被覆盖（如 GUID 中间 10 字节变
0x656565...）→ 触发 8929/8976 类错误 →REPAIR_REBUILD通常能保留该页，但字段值已不可逆损坏 - 页链接指针被破坏（
m_nextPage指向非法页号）→ B树断裂 →REPAIR_REBUILD会重建索引，原页可能被隔离，但数据仍可通过DBCC PAGE读出
先抢救：用 EMERGENCY 模式把数据捞出来
损坏页还在磁盘上，只要数据库能启动到 EMERGENCY 状态，你就能绕过锁和一致性检查，直接读原始数据。
执行顺序必须严格：
ALTER DATABASE [YourDB] SET EMERGENCY;ALTER DATABASE [YourDB] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;- 立刻执行
SELECT * FROM [YourTable] WITH (NOLOCK)—— 这时即使页损坏，SQL Server 仍可能返回部分可读行 - 若某页完全无法读取（报 823/824），用
DBCC PAGE('YourDB', file_id, page_id, 3)查看原始十六进制内容，手动提取还能识别的字段（比如 ASCII 字符段、日期高位字节） - 导出可用数据后，再考虑修复或重建
REPAIR_REBUILD 能做什么、不能做什么
这是最常被低估也最该优先试的选项。它不会删除页，而是重建索引结构，把损坏页里的有效行重新插入新页中——前提是这些行本身没被逻辑破坏（比如 key 值乱码导致无法排序）。
- 适用场景：
DBCC CHECKDB报错含 “repair_rebuild is the minimum repair level”；错误号为 8976、8977、8978（B树链断裂） - 不适用场景：页校验和失败（824）、页头类型错误（8909）、分配单元不匹配（8966）——这些会跳过
REPAIR_REBUILD直接要求ALLOW_DATA_LOSS - 注意：
REPAIR_REBUILD需要足够tempdb空间，且会阻塞所有用户操作；它重建的是索引，不是堆表数据页本身 - 对堆表（无聚集索引），
REPAIR_REBUILD无效，得靠ALTER TABLE ... REBUILD或导出+重建
真正危险的操作：别在没备份时跑 REPAIR_ALLOW_DATA_LOSS
这个命令一旦执行，SQL Server 会永久移除它认为“无法修复”的页，并更新 IAM、PFS 等分配位图。没有回滚，没有日志记录，也没有提示你哪几行丢了。
容易被忽略的关键点：
- 它不区分“你手动改坏的页”和“其他正常页”——只要一个页被标记为损坏，整个分配单元都可能被扫描清理
- 如果损坏页里有 LOB 数据（
varchar(max)、varbinary(max)），REPAIR_ALLOW_DATA_LOSS往往直接删掉整条记录，而不是只删 LOB 列 - 执行前必须确认数据库处于
SINGLE_USER模式，否则命令静默失败；执行后必须手动切回MULTI_USER，否则应用连不上 - 修复后务必立即执行
DBCC CHECKDB验证，因为有些深层损坏（如系统表引用）可能在修复后才暴露
最稳妥的做法永远是：先 EMERGENCY 捞数据，再评估是否值得用 REPAIR_ALLOW_DATA_LOSS 换取一个能上线的空壳库。
