alter index rebuild 是否锁表取决于是否指定 online = on；企业版默认离线重建（锁表），标准版2022前不支持在线，azure sql及新版standard支持；未加online时dml被阻塞，select可能等待；即使支持online也需额外空间和日志资源。
alter index rebuild 会锁表吗？
取决于是否加 ONLINE = ON。SQL Server 企业版默认是离线重建（锁整个表），标准版不支持在线重建；Azure SQL 和较新版本的 Standard Edition（2022 起）才逐步放开限制。
- 没加
ONLINE = ON：重建期间SELECT可能被阻塞，INSERT/UPDATE/DELETE直接失败或长时间等待 - 加了但版本不支持：SQL Server 直接报错
Msg 155, Level 15, State 1: 'ONLINE' is not a recognized ALTER INDEX option. - 即使支持
ONLINE = ON，仍需额外空间（约 1.2× 索引大小），且重建过程会产生大量日志，可能撑爆tempdb或事务日志
什么时候该用 REBUILD 而不是 REORGANIZE？
REBUILD 是彻底重建索引结构，适合高碎片（>30%）、页密度低、或需要修改索引属性（如填充因子、压缩选项）的场景；REORGANIZE 是原地整理，轻量、在线、低资源占用，但无法修复分配碎片或重置统计信息。
- 碎片率 > 30% → 优先
REBUILD - 碎片率 5%–30% →
REORGANIZE更稳妥 - 想改
FILLFACTOR或启用DATA_COMPRESSION→ 必须REBUILD - 运行在只读副本或 AG secondary 上 →
REBUILD不被允许，只能REORGANIZE
REBUILD 的常见参数陷阱
看似简单的命令，几个参数配错就会导致意外行为或失败。
-
WITH (SORT_IN_TEMPDB = ON)：加快排序但吃tempdb空间；若tempdb不足，重建直接中止 -
WITH (MAXDOP = 1)：避免并行争抢资源，但延长执行时间；线上 OLTP 表慎用高MAXDOP，易引发 CXPACKET 等等待 -
WITH (STATISTICS_NORECOMPUTE = OFF)：默认开启自动更新统计信息；设为ON后，后续查询可能因过期统计走错执行计划 - 漏写
ONLINE = ON却以为是在线操作 → 生产环境变更前务必用SELECT @@VERSION和SELECT DATABASEPROPERTYEX('dbname', 'Edition')确认能力边界
如何安全触发在线重建而不中断业务？
没有银弹，只有分层控制：先评估、再限流、最后监控。
- 查碎片：用
sys.dm_db_index_physical_stats，别信 SSMS 图形界面里那个“碎片 %”数字（它默认只采样 100 页） - 避开高峰：结合
sys.dm_exec_requests和sys.dm_os_wait_stats观察当前阻塞和等待类型，确认低负载窗口 - 加超时保护：在 Agent Job 或脚本里包装
WAITFOR DELAY '00:30:00'+ 检查sys.indexes.is_disabled，防止卡死 - 重建后立刻验证：跑
DBCC SHOW_STATISTICS ('table', 'index') WITH DENSITY_VECTOR看行数是否更新，防“重建成功但统计信息没刷新”这种静默失效
SELECT 在显式事务里挂着，REBUILD 就会一直等，而你只看到“正在运行”，看不出卡在哪。
