小编Fza*_*Fza的帖子

我的印象是，当LIKE在所有针对未知场景的优化中使用运算符时，旧版和新版 CE 都使用 9% 的估计值（假设相关统计数据可用并且查询优化器不必求助于选择性猜测）。

当对信用数据库执行以下查询时，我在不同的 CE 下得到不同的估计。在新的 CE 下，我收到了我期望的 900 行的估计值，在旧版 CE 下，我收到了 241.416 的估计值，但我无法弄清楚这个估计值是如何得出的。有没有人能够发光？

-- New CE (Estimate = 900)
DECLARE @LastName VARCHAR(15) = 'BA%'
SELECT * FROM [Credit].[dbo].[member]
WHERE [lastname] LIKE @LastName;

-- Forcing Legacy CE (Estimate = 241.416)
DECLARE @LastName VARCHAR(15) = 'BA%'
SELECT * FROM [Credit].[dbo].[member]
WHERE [lastname] LIKE @LastName
OPTION (
QUERYTRACEON 9481,
QUERYTRACEON 9292,
QUERYTRACEON 9204,
QUERYTRACEON 3604
);

在我的场景中，我已经将信用数据库设置为兼容性级别 120，因此为什么在第二个查询中我使用跟踪标志来强制使用旧版 CE 并提供有关查询优化器使用/考虑的统计信息的信息。我可以看到正在使用有关“姓氏”的列统计信息，但我仍然无法弄清楚 241.416 的估计值是如何得出的。

除了这篇 Itzik Ben-Gan 文章之外，我在网上找不到任何其他 …

我正在对同步与异步自动统计更新进行一些测试。我想快速使所有统计对象（标题、密度向量和直方图）失效，以确保下次使用统计时会更新。

我正在尝试模拟统计数据的自动更新，而不是自动创建。

理想情况下，我不想更改行数，因此我已取消INSERT/DELETE操作。理想情况下，我也不想更改任何数据值，我已经考虑使用UPDATE语句，但我认为这在我的一些较大的表上可能需要太长时间。

我已经看过了，UPDATE STATISTICS WITH ROWCOUNT, PAGECOUNT但我认为这不是我所追求的。我希望可能有一个跟踪标志或未记录的命令会使统计数据无效。

有没有一种快速有效的方法来完成我没有考虑过的我想要实现的目标？

我正在 SQL Server 2016 上进行测试。

我在 SQL Server 2016 EE 实例上有一个相对较大的 550GB 数据库，该实例的最大内存限制为操作系统可用的总 128GB RAM 中的 112GB。数据库的最新兼容级别为 130。开发人员抱怨下面的查询在隔离执行时在他们可接受的 30 秒内执行，但是当他们大规模运行他们的进程时，同一查询会并发执行多次跨多个线程，这是他们观察到执行时间受到影响并且性能/吞吐量下降的时候。有问题的 T-SQL 是：

select distinct dg.entityId, et.EntityName, dg.Version
                     from DataGathering dg with(nolock) 
                     inner join entity e with(nolock) 
                           on e.EntityId = dg.EntityId
                     inner join entitytype et with(nolock)   
                         on et.EntityTypeID = e.EntityTypeID  
                         and et.EntityName = 'Account_Third_Party_Details' 
                     inner join entitymapping em with(nolock)   
                         on em.ChildEntityId = dg.EntityId  
                         and em.ParentEntityId = -1  
                     where dg.EntityId = dg.RootId  

    union all

select distinct dg1.EntityId, et.EntityName, dg1.version
                     from datagathering dg1 with(nolock)  
                     inner join entity e …

我正在尝试调整以下查询，无论将什么值作为参数传入，该查询都需要 15-16 秒，查询是：

select distinct d.documentpath as path, d.documentname as name, d.datecreated as created, pc.DateProcessed
from datagatheringruntime dgr 
 inner join processentitymapping pem on pem.entityid = dgr.entityid 
 inner join document d on d.entityid = pem.entityid or d.unitofworkid = pem.processid
 left join PendingCorrespondence pc on pc.PendingCorrespondenceId = d.PendingCorrespondenceId
 where rootid = @P0 and dgr.name in('cust_pn', 'case_pn')
OPTION(RECOMPILE)

我已经更新了查询涉及的所有表的统计信息（不包括DataGatheringRuntime在 ~ 处相当大的表100GB），并尝试使用 a 重新分解查询，CTE但获得相同的执行计划并需要一些帮助。

实际的执行计划可以在这里找到：

https://www.brentozar.com/pastetheplan/?id=ByUVIqlFE

这是从执行计划明确指出，问题在于对外部输入nested loop join与特别是lazy table spool以下的scan非群集的IX_Camunda_1 …

我使用下面的 T-SQL 查询来确定上次完整数据库备份的日期，并返回备份文件的大小和位置。我的问题是，对于没有备份或没有备份历史记录的数据库，它根本不会返回任何数据。理想情况下，我想修改查询以便返回所有数据库，无论它们是否有任何备份历史记录。任何人都可以建议如何修改以下查询以适应此情况？

WITH LastBackUp AS
(
SELECT  bs.database_name,
        bs.backup_size,
        bs.backup_start_date,
        bmf.physical_device_name,
        Position = ROW_NUMBER() OVER( PARTITION BY bs.database_name ORDER BY bs.backup_start_date DESC )
FROM  msdb.dbo.backupmediafamily bmf
JOIN msdb.dbo.backupmediaset bms ON bmf.media_set_id = bms.media_set_id
JOIN msdb.dbo.backupset bs ON bms.media_set_id = bs.media_set_id
WHERE   bs.[type] = 'D'
AND bs.is_copy_only = 0
)
SELECT 
        database_name AS [Database],
        CAST(backup_size / 1048576 AS DECIMAL(10, 2) ) AS [BackupSizeMB],
        backup_start_date AS [Last Full DB Backup Date],
        physical_device_name AS [Backup File Location]
FROM LastBackUp
WHERE Position = …

有很多关于可用于减轻不良参数嗅探的某些方法的极好信息，但关于如何识别不良参数嗅探问题的信息并不多。

假设您没有使用 SQL Server 2016，因此无法利用查询存储，并且您没有用户抱怨有问题的存储过程间歇性地执行不佳，那么可以使用哪些方法来主动识别错误的参数嗅探问题？

利用扩展事件、RML 实用程序和简单地查询/轮询 DMV 似乎都是可行的方法，有没有人有使用这些方法中的任何一个的方法或知道任何描述如何执行此操作的好资源？