日常运行的批量更新作业，平日是5分钟之内结束，今天出现超过30分钟没结束的情况，实际运行3个小时以上，应用程序超时报错。数据库版本：SQL Server 2016企业版问题SQL:
declare @batch integer,
@min integer,
@max integer,
@count integer
select @min = 1,
@count = count(*),
@batch = 5000,
@max = 5000
FROM dbo.MarketingRecipientEvents
Update MarketingRecipient
SET DateTrackedURLClicked = mre.EventDate
FROM MarketingRecipient mr
INNER JOIN dbo.MarketingRecipientEvents mre on mr.CustomerID = mre.ExternalRecipientID
WHERE mr.MarketingScheduleID = 364
AND mre.EventType in ('CLICKED')
AND mr.DateTrackedURLClicked IS NULL
AND mre.MarketingRecipientEventsID between @min and @max
问题表上MarketingRecipient上有两个相同覆盖列索引，正常情况下使用出问题的时候使用ix_MarketingRecipient_MarketingScheduleID_CustomerID 进行Nested Loop 连接，出问题的时候使用IX_MarketingRecipient_MarketingScheduleID_DateMessageBounced进行Nested Loop连接
CREATE NONCLUSTERED INDEX [ix_MarketingRecipient_MarketingScheduleID_CustomerID] ON [dbo].[MarketingRecipient] ( [MarketingScheduleID] ASC, [CustomerID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [DATA] GO CREATE NONCLUSTERED INDEX [IX_MarketingRecipient_MarketingScheduleID_DateMessageBounced] ON [dbo].[MarketingRecipient] ( [MarketingScheduleID] ASC ) INCLUDE ( [CustomerID], [DateMessageBounced], [DateMessageSent], [DateEmailOpened], [DateEmailBlocked], [MarketingRecipientID], [DateTrackedURLClicked])
问题执行计划：
查看执行计划对应的统计信息：
SELECT sp.stats_id ,object_name(s.object_id) object_name ,object_schema_name(s.object_id) schema_name ,name ,filter_definition ,last_updated ,rows ,rows_sampled ,rows_sampled*100/rows as [percent] ,steps ,unfiltered_rows ,modification_counter ,sp.persisted_sample_percent FROM sys.stats s CROSS APPLY sys.dm_db_stats_properties(s.object_id, s.stats_id) AS sp WHERE 1=1 and modification_counter < rows/5 + 500 and modification_counter > sqrt(rows*1000) and object_schema_name(s.object_id) = 'dbo' and rows > 500 and object_name(s.object_id)= 'MarketingRecipient';
发现modification_counter列的值不低：
目前数据库刚迁移到2016版本，但是compatibility_level依旧是120并且没有启用trace 2371，所以，自动更新统计信息的逻辑是：更新行>500+表行数*20% = 500+ 36891356*20%=7378771, 目前行数5718611不满足条件，所以统计信息不完善导致执行计划异常，优化器并没有捕捉到如果使用新的自动更新统计信息逻辑：更新行>
√表行数*1000=
√36891356*1000=192071， 5718611满足条件，验证一下：不改代码的情况下给SQL加plan guide:
OPTION (QUERYTRACEON 2371)
发现统计信息在编译期间自动更新，并且生成正确的执行计划。
本例是数据库从2014企业版到2016企业版升级过程中间状态造成的性能问题，生产环境如果要启用compability_level=130,在2016环境下建议以下步骤
先启用querystore建立基线，收集足够的统计数据。
更改 compability_level=130
对比基线数据，捕获变更的计划进行针对性的query plan force操作，固定到之前的基线。
在没有升级到compability_level=130的情况下，建议建立DBA更新统计信息的job，每晚根据新的算法更新过期的统计信息。也可以利用 https://github.com/olahallengren/sql-server-maintenance-solution 中的 IndexOptimize.sql 进行统计信息维护，利用新的参数：@StatisticsModificationLevel来设置更改行数占表总行数百分比。
