SQL Server无全库索引重建命令，需用存储过程动态遍历+条件判断：先用sys.dm_db_index_physical_stats筛选高碎片（≥30%且页数≥1000）或中碎片（5%-30%）索引，再按阈值自动选择REBUILD或REORGANIZE，并补更新统计信息。
SQL Server里没有“全库索引重建”内置命令
SQL Server 不支持类似 OPTIMIZE DATABASE 的语法，也不存在一个 T-SQL 命令能一键重建整个数据库所有索引。必须靠动态 SQL + 循环遍历实现，而存储过程是唯一可控、可复用的封装方式。直接写 ALTER INDEX ALL ON ? REBUILD 在普通批处理里能跑，但在存储过程中无法参数化表名，硬写会报错 ERROR 102 或 ERROR 156。
用 sys.dm_db_index_physical_stats 筛出真正需要处理的索引
别一上来就全量重建——小索引（page_count ）、低碎片（<code>avg_fragmentation_in_percent ）重建收益极低，反而加重 I/O 和锁压力。应优先查出高价值目标：
<ul>
<li>只查当前数据库：<code>DB_ID() 而非 NULL 作为第一个参数
OBJECT_NAME(ps.object_id) NOT LIKE 'sys%' 且排除 tempdb 相关表i.index_id > 0
'LIMITED'（快），仅对碎片 >30% 或页数 >5000 的才考虑切 'DETAILED'
REORGANIZE 和 REBUILD 必须按阈值自动分流
强行统一用 REBUILD 会卡死业务，全用 REORGANIZE 又清不干净重度碎片。正确做法是在循环中根据实时查出的 avg_fragmentation_in_percent 值做判断：
- 碎片率 ≥ 30% 且
page_count ≥ 1000→ 拼ALTER INDEX ... REBUILD WITH (ONLINE = ON)（企业版）或降级为REBUILD（标准版） - 碎片率在 5%–30% 之间 → 拼
ALTER INDEX ... REORGANIZE - 每次拼接前检查
OBJECTPROPERTY(object_id, 'IsUserTable') = 1，避开视图、函数返回表等伪对象 - 记得给
REBUILD加FILLFACTOR = 90，避免后续插入频繁页分裂
执行阶段必须处理锁、超时和权限断点
存储过程不是“启动就完事”，它会在每个 EXECUTE 处真实阻塞或等待。几个关键断点常被忽略：
-
REBUILD默认会请求SCH-M锁，若此时有长事务持有SCH-S，就会卡住；需提前检查sys.dm_exec_requests中阻塞链 - 单个语句超时由
command_timeout控制，但存储过程内无全局设置，建议在每条EXEC sp_executesql前加SET LOCK_TIMEOUT 30000（30秒） - 必须拥有
ALTER权限——仅db_owner角色不一定够，某些数据库启用了更细粒度权限控制 - 不要依赖
TRY...CATCH捕获所有错误：像Msg 15023（用户已存在）或Msg 1947（ONLINE 不可用）需单独判别并跳过，否则中断整个流程
最易被忽略的是统计信息更新：无论 REORGANIZE 还是 REBUILD 都不会自动触发 UPDATE STATISTICS，必须在每轮操作后显式补一句 UPDATE STATISTICS [schema].[table] WITH FULLSCAN，否则查询计划可能继续走歪。
