Azure SQL索引重建是否会耗尽存储？存储不足前需做哪些准备？

咱们先拆解问题，分两部分来说明：

一、当数据库达600GB且重建索引所需空间超1TB时会发生什么？ #

Azure SQL DB的容量限制是硬阈值，当你的数据库当前大小（600GB）加上索引重建所需的临时空间总和超过1TB时，索引重建操作会直接失败，系统会抛出类似“数据库空间不足”的错误。

这里要注意：默认的REBUILD ONLINE操作会在用户数据库内分配临时空间来存放新索引（直到重建完成后替换旧索引），这个临时空间是算入数据库总容量的。如果是离线重建，不仅会锁表影响业务，同样会因为空间不足导致失败，甚至可能留下半完成的索引碎片，反而增加后续维护的麻烦。

二、现在应采取的提前应对措施 #

针对你的场景，推荐按优先级采取以下措施：

• 优先评估索引重建的必要性，替换为轻量操作：不是所有索引都需要全量重建。对于碎片率低于30%的索引，改用ALTER INDEX ... REORGANIZE命令，这个操作是原地整理碎片，几乎不需要额外空间，只是效率略低，但能避免空间占用问题。你可以用以下查询查看索引碎片率：

  SELECT 
      OBJECT_NAME(ips.object_id) AS TableName,
      i.name AS IndexName,
      ips.avg_fragmentation_in_percent
  FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'DETAILED') ips
  JOIN sys.indexes i ON ips.object_id = i.object_id AND ips.index_id = i.index_id
  WHERE ips.avg_fragmentation_in_percent > 10; -- 筛选需要处理的索引
  

• 分批重建大索引：不要一次性处理所有大索引，每次只重建一个，等操作完成后，旧索引会被自动清理，释放出空间再处理下一个。如果你的大表是分区表，可以按分区分批重建索引，每个分区的重建空间需求会大幅降低。
• 重建时启用数据压缩：在重建索引时加上WITH (DATA_COMPRESSION = PAGE)（或ROW级压缩，根据业务场景选择），这样重建后的索引体积会显著减小，既节省长期存储成本，也能降低重建时的临时空间需求。比如：

  ALTER INDEX ALL ON YourLargeTable REBUILD WITH (DATA_COMPRESSION = PAGE, ONLINE = ON);
  

• 归档冗余历史数据：对大表中的历史冷数据进行归档，比如将超过一定时间的数据迁移到Azure Blob存储或更低成本的归档数据库中。推荐用分区切换的方式，高效且几乎不影响在线业务，这样主表的大小会直接降低，索引重建的空间需求也会随之减少。
• 临时扩容数据库容量：如果必须进行全量索引重建，可以临时将数据库升级到支持更大容量的层级（比如通用层最大支持8TB），完成重建后再缩回到原层级。虽然会产生临时的额外成本，但能快速解决空间不足的问题，注意操作要在业务低峰期进行。

内容的提问来源于stack exchange，提问作者MIKE