移除现有SQL表分区的最优操作顺序探讨

针对你提到的分区移除耗时问题，核心优化思路是避免全量删除再重建所有索引，通过调整聚集索引的重建方式，减少不必要的IO操作，具体优化步骤如下：

优化后的操作步骤 #

1. 直接迁移聚集索引到PRIMARY文件组
   不需要先删除现有分区的聚集索引，而是使用DROP_EXISTING = ON参数直接重建聚集索引到PRIMARY文件组，这样非聚集索引会自动同步更新为非分区状态，无需提前删除：

   CREATE CLUSTERED INDEX [PK_YourTableName]
   ON [dbo].[YourTableName]([YourPrimaryKeyColumn])
   WITH (
       DROP_EXISTING = ON,
       ONLINE = ON, -- 减少锁表时间，Azure SQL支持该参数
       MAXDOP = 1 -- 根据环境调整并行度，避免资源耗尽
   )
   ON [PRIMARY];
   

   这个操作会一次性完成数据从分区到PRIMARY文件组的迁移，同时保留非聚集索引的结构，仅更新其分区关联关系。

2. 删除分区方案与函数
   当聚集索引不再关联分区方案后，即可安全执行：

   DROP PARTITION SCHEME [YourPartitionSchemeName];
   DROP PARTITION FUNCTION [YourPartitionFunctionName];
   

3. 按需调整非聚集索引
   此时非聚集索引已自动转为非分区状态，仅需根据索引碎片率选择性重建或重新组织，而非全部删除再创建：

   -- 查看索引碎片
   SELECT 
       name AS IndexName,
       avg_fragmentation_in_percent
   FROM sys.dm_db_index_physical_stats(
       DB_ID(), OBJECT_ID('dbo.YourTableName'), NULL, NULL, 'DETAILED'
   );
   
   -- 碎片率>30%时重建，<30%时重新组织
   ALTER INDEX [IX_YourIndexName] ON [dbo].[YourTableName] REBUILD WITH (ONLINE = ON);
   -- 或
   ALTER INDEX [IX_YourIndexName] ON [dbo].[YourTableName] REORGANIZE;
   

原步骤耗时的原因 #

原流程中先删除所有索引（包括聚集索引）会将表转为堆结构，之后重建聚集索引需要全量排序数据，再重建所有非聚集索引又要全量扫描数据，三次全量IO操作是耗时的核心原因。优化后的流程仅需一次聚集索引的重建操作，非聚集索引自动同步，大幅减少IO开销。

额外注意事项 #

• 在线操作（ONLINE = ON）需确保Azure SQL版本支持（一般vCore和DTU模式的高级层都支持），可在业务低峰期执行以降低影响。
• 若表上有外键约束，需提前确认约束是否依赖分区键，避免操作失败。

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