如何编写能够自动修复坏索引的存储过程_利用ALTER INDEX REBUILD语句-SQL-PHP中文网

“坏索引”非标准术语，实指两类问题：一是碎片高（avg_fragmentation_in_percent > 30），可用alter index rebuild修复；二是结构损坏（dbcc checkdb报msg 89xx），rebuild无效，须repair_allow_data_loss或还原备份。

如何编写能够自动修复坏索引的存储过程_利用alter index rebuild语句

SQL Server 中无法靠单个存储过程“自动修复所有坏索引”——因为“坏索引”本身不是标准概念，而 ALTER INDEX REBUILD 只能处理可识别的物理碎片或禁用状态，不能修复逻辑损坏（如页校验和失败、索引键不一致等）。

什么是真正的“坏索引”？先分清两类问题

用户常把“查询变慢”“执行计划走错”归为“索引坏了”，但背后原因完全不同：

sys.dm_db_index_physical_stats 返回 avg_fragmentation_in_percent > 30：这是**碎片高**，ALTER INDEX REBUILD 有效
DBCC CHECKDB 报出 Msg 89xx（如 8946、8966）：这是**结构损坏**，REBUILD 无效，必须用 REPAIR_ALLOW_DATA_LOSS 或从备份恢复
索引被手动 DISABLE：状态为 is_disabled = 1，此时 REBUILD 可启用并重建

如何安全地自动重建高碎片索引？

核心是过滤出真正适合 REBUILD 的索引，并避开系统表、只读文件组、内存优化表等不支持场景：

只处理 index_type IN (1, 2)（聚集/非聚集索引），跳过堆（0）、XML、空间、列存储索引
排除 is_disabled = 1 的索引（需先 ENABLE，但 REBUILD 自动包含该行为）
检查 has_filter = 1 的筛选索引：SQL Server 2012+ 支持在线重建，但低版本需显式加 ONLINE = OFF
对大表考虑加 MAXDOP = 1 避免并行阻塞，或用 WAIT_AT_LOW_PRIORITY（SQL Server 2014+）减少锁影响

示例判断逻辑（放入存储过程循环中）：

SELECT 
  QUOTENAME(s.name) + '.' + QUOTENAME(t.name) AS table_name,
  QUOTENAME(i.name) AS index_name,
  ps.avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') ps
JOIN sys.indexes i ON ps.object_id = i.object_id AND ps.index_id = i.index_id
JOIN sys.tables t ON i.object_id = t.object_id
JOIN sys.schemas s ON t.schema_id = s.schema_id
WHERE ps.avg_fragmentation_in_percent > 30
  AND i.index_id > 0 -- 排除堆
  AND i.is_disabled = 0
  AND t.is_ms_shipped = 0;

哪些情况绝对不能用 ALTER INDEX REBUILD？

强行执行会报错或无效，必须提前拦截：

目标索引在 READ_ONLY 文件组上 → 报错 Msg 1927
数据库处于 READ_ONLY 模式 → 报错 Msg 3902
索引属于内存优化表（is_memory_optimized = 1）→ 不支持 REBUILD，只能 ALTER TABLE ... REBUILD
索引含计算列且底层函数为非确定性（如 GETDATE()）→ REBUILD 失败，报 Msg 2729
正在做完整备份或日志备份期间，ONLINE = ON 可能因锁升级失败 → 建议加 TRY...CATCH 并降级为 OFFLINE