数据库 SQL Server 2017 Enterprise CU16 14.0.3076.1
我们最近尝试从默认的 Index Rebuild 维护作业切换到 Ola Hallengren IndexOptimize。默认的索引重建作业已经运行了几个月没有任何问题，并且查询和更新的执行时间在可接受的范围内。在IndexOptimize数据库上运行后：
EXECUTE dbo.IndexOptimize
@Databases = 'USER_DATABASES',
@FragmentationLow = NULL,
@FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationLevel1 = 5,
@FragmentationLevel2 = 30,
@UpdateStatistics = 'ALL',
@OnlyModifiedStatistics = 'Y'
性能极度下降。之前花费 100 毫秒的更新语句在之后IndexOptimize花费了 78.000毫秒（使用相同的计划），并且查询的性能也差了几个数量级。
由于这仍然是一个测试数据库（我们正在从 Oracle 迁移生产系统），我们恢复到备份并禁用IndexOptimize，一切恢复正常。
但是，我们想了解什么IndexOptimize与Index Rebuild可能导致这种极端性能下降的“正常”不同，以确保我们在投入生产后避免这种情况。任何关于寻找什么的建议将不胜感激。
更新语句缓慢时的执行计划。即
IndexOptimize 之后的
实际执行计划（即将推出）
我一直无法发现差异。
快速时为同一个查询做
计划 实际执行计划