如何在SQL Server中重建碎片化严重的索引视图-SQL-PHP中文网

不能直接对索引视图执行 ALTER INDEX ... REBUILD，因为索引视图的聚集索引与其定义强绑定、不可单独操作，必须通过 DROP VIEW + CREATE VIEW + 创建唯一聚集索引来重建整个视图。

如何在sql server中重建碎片化严重的索引视图

不能直接对索引视图执行 ALTER INDEX ... REBUILD，必须重建底层索引视图本身。

为什么不能用标准的 ALTER INDEX REBUILD 重建索引视图

SQL Server 中的“索引视图”本质是带唯一聚集索引的视图（即物化视图），它不是普通表上的索引，而是一个独立的数据库对象。因此 ALTER INDEX 语句只接受表或索引视图的名称作为 ON 子句的目标，但不支持在该目标上指定其内部索引名——因为它的聚集索引就是视图本身。

常见错误现象：ALTER INDEX [IX_MyIndexedView] ON [dbo].[MyIndexedView] REBUILD 会报错：Msg 1516, Level 16, State 1: Index 'IX_MyIndexedView' does not exist on object 'MyIndexedView'（即使该索引在 sys.indexes 中可见）。

索引视图的聚集索引无法单独重建；它与视图定义强绑定
sys.dm_db_index_physical_stats 能查到索引视图的碎片（object_id 对应视图ID，index_id = 1 表示其聚集索引），但这只是逻辑呈现，不是可操作的独立索引
试图对视图名运行 ALTER INDEX ALL ON ... 同样失败，因为视图不支持 ALL 模式

正确做法：用 CREATE OR ALTER VIEW + DROP + CREATE 重建整个索引视图

核心思路是：先禁用（隐式删除）原索引视图及其所有索引，再以相同定义重新创建。这等效于“重建”，且会生成全新、无碎片的聚集索引页。

实操建议：

确保视图定义中包含 WITH SCHEMABINDING 和 CREATE UNIQUE CLUSTERED INDEX（这是索引视图的前提）
执行前检查依赖：SELECT referencing_entity_name, referencing_class_desc FROM sys.dm_exec_referencing_entities('dbo.MyIndexedView', 'OBJECT')
若视图被其他视图/函数引用，需确认 SCHEMABINDING 兼容性，否则 DROP 会失败

推荐脚本流程（需在事务中谨慎执行）：

SET XACT_ABORT ON;
BEGIN TRANSACTION;
<p>DROP VIEW IF EXISTS [dbo].[MyIndexedView];</p><p>-- 粘贴原始 CREATE VIEW ... WITH SCHEMABINDING 语句
CREATE VIEW [dbo].[MyIndexedView]
WITH SCHEMABINDING
AS
SELECT ... -- 原始逻辑
GO</p><p>-- 立即创建聚集索引（必须在 CREATE VIEW 后立刻执行）
CREATE UNIQUE CLUSTERED INDEX [IX_MyIndexedView] 
ON [dbo].[MyIndexedView] ([Col1], [Col2]);
GO</p><p>COMMIT;</p>

重建时必须注意的三个关键点

忽略任一都会导致重建失败或性能未改善：

填充因子不能继承：新创建的聚集索引默认使用服务器级默认填充因子（通常是 0/100）。如需控制页面密度，必须显式在 CREATE UNIQUE CLUSTERED INDEX 语句中加 WITH (FILLFACTOR = 80)
ONLINE 选项受限：SQL Server Standard Edition 不支持对索引视图的在线重建（WITH (ONLINE = ON) 会报错）。只有 Enterprise Edition 支持，且要求数据库兼容级别 ≥ 120
tempdb 使用量激增：重建过程会大量使用 tempdb 排序空间，尤其当视图结果集巨大时。务必确认 tempdb 文件组有足够空间，否则会中途失败并回滚整个事务