SQL Server调整decimal列精度标度是否影响现有非聚集索引

你示例代码中「先删除关联非聚集索引→修改decimal列精度/标度→重建索引」的操作不属于冗余操作，反而针对1亿行级、访问负载极高的业务表是必要的性能优化手段，完全建议保留这套操作逻辑。

• 别信网上“同存储长度类型修改是秒级元数据操作”的通用说法，这个规则仅适配varchar/nvarchar的不超长度上限扩容场景，对decimal类型完全不生效：哪怕新旧decimal的精度都落在10-19区间、固定占9字节存储，只要precision或scale任意一个值变化，数据库引擎就需要逐行扫描重写该列的存储值、校验数据合法性，本质是全表数据重写操作，不存在秒级完成的可能。
• 如果不提前删除关联索引，直接执行ALTER COLUMN语句：引擎在全表重写数据的过程中，会同步维护所有关联该列的非聚集索引。1亿行数据规模下，这个操作的事务日志生成量会是先删索引方案的2~3倍，锁持有时间会拉长数倍，高负载场景下极易触发大面积业务阻塞、甚至事务日志空间被撑爆的故障。
• 不存在“改列后原索引可自动复用无需处理”的可能：decimal列存储格式变化后，原索引的键值物理存储已经完全失效，哪怕你不手动删除索引，引擎也会在改列过程中自动重建关联索引。但这个自动重建过程是黑盒，无法自定义SORT_IN_TEMPDB、ONLINE、并行度等优化参数，执行效率和对业务的友好度远差于手动可控的重建流程。

你提供的基础脚本逻辑正确，针对大表高负载场景可以微调索引创建参数，进一步降低操作对业务的影响，所有操作必须放在业务低峰窗口执行：

DROP INDEX IF EXISTS [IX_Index] ON [dbo].[TableName]
GO
ALTER TABLE dbo.[TableName]
ALTER COLUMN DecimalField DECIMAL(14, 9) NOT NULL
GO
IF NOT EXISTS(SELECT * FROM sys.indexes WHERE name='IX_Index' AND object_id = OBJECT_ID('dbo.TableName'))
BEGIN
    CREATE NONCLUSTERED INDEX [IX_Index] ON [dbo].[TableName]
    (
        DecimalField ASC
    ) WITH (
        PAD_INDEX = OFF, 
        STATISTICS_NORECOMPUTE = OFF, 
        SORT_IN_TEMPDB = ON, -- 大表建议开启，利用tempdb分担排序IO压力
        DROP_EXISTING = OFF, 
        ONLINE = ON, -- 仅企业版/开发者版支持，创建索引期间不阻塞表的正常读写
        ALLOW_ROW_LOCKS = ON, 
        ALLOW_PAGE_LOCKS = ON, 
        OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF,
        MAXDOP = 4 -- 根据实例CPU核数灵活调整，并行创建加快索引生成速度
    )
END

注意：如果你使用的SQL Server版本不支持ONLINE=ON选项，务必提前做好流量切走或短暂停服的准备，避免长时间锁表影响线上业务可用性。

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