小编Nie*_*jes的帖子

我们的 ERP 系统存在一些性能问题。06:00 左右，问题开始出现。长话短说; 我的一位同事执行了DBCC FREEPROCCACHE（我知道这不是首选操作，但这不是重点）。之后，他重新启动了整个 ERP 应用程序，而不是数据库引擎。这似乎没有帮助。我查看了查询存储，发现查询计划在 06:05 左右发生了更改。我尝试强制执行旧计划，性能问题就消失了。

我比较了 2 个计划 XML，发现两者都基于相同的统计数据（更新日期完全相同）。索引上的更改数量不同，但这不会触发更新统计信息，因为否则新的查询计划将为所使用的统计信息提供新的日期。我检查了涉及的表的所有统计信息，但自上次维护工作以来，它们没有更新。最后一次维护作业在本周末运行，这也是两个查询计划中使用的统计信息的更新日期。

该查询是参数化查询，所以我有点不清楚为什么查询计划突然改变。我认为恰恰相反，查询突然运行缓慢，因为相同的计划用于不同的参数。这里的情况似乎并非如此，因为我强制使用旧的查询计划。

该查询来自一些检索订单的定制工作。现在，我怀疑有人发出了参数化查询，该查询会返回一个非常大的数据集，从而减慢 ERP 系统的速度。然后，我的同事运行了一个DBCC FREEPROCCACHE命令，根据本周末的新统计数据触发了查询计划的重新编译。当前查询继续运行，他决定重新启动 ERP 应用程序。现在，使用新的查询计划，所有新查询都会变慢，直到我强制使用旧的查询计划。

这能是解释吗？我有点怀疑，因为当统计数据发生变化时，SQL Server会触发重新编译，所以计划应该在索引维护作业之后已经重新编译。

我想我在这里遗漏了一些东西，但我不确定是什么。它是SQL Server 2016 Standard，是ERP系统的专用服务器。

编辑 15-4-2020 12:17：既然我写了这个...我认为问题在于DBCC FREEPROCCACHE第一次执行有问题的参数化查询的参数使用了不同的参数，这导致 SQL Server 重新编译（坏）计划。或者我还缺少什么吗？

我遇到一个问题，我不断从下面的查询中获取值“CtP_PETER_Fact”。它应该是区分大小写的 where 子句。我尝试了几种不同的方法：在选择中的“Where ObjectName”之后、正则表达式之后设置 COLLATE 语句，并使用排序规则创建列。我不断得到我意想不到的输出。也许是我的正则表达式有问题？我也对正则表达式进行了很多实验，但似乎无法让它发挥作用。

IF OBJECT_ID('tempdb..#nameFacts') IS NOT NULL
DROP TABLE #nameFacts;


CREATE TABLE #nameFacts (


    objectname varchar(200) COLLATE SQL_Latin1_General_CP1_CS_AS,
    ObjectType varchar(40)

)


insert into #nameFacts (objectname, ObjectType)
values
 ('BPD_Inslap_Fact','Fact')
,('CTP_HENK_FACT','Fact')
,('CTP_PETER_Fact','Fact')
,('CTP_PETER_FACT','Fact')
,('CtP_PETER_Fact','Fact')
,('C0P_PETER_Fact','Fact')
,('C0P_PETER_FACT','FACT')


SELECT *
FROM #nameFacts
WHERE
ObjectName --COLLATE SQL_Latin1_General_CP1_CS_AS 
            LIKE '[A-Z0-9][A-Z][A-Z][_][A-Z][A-Z][A-Z][A-Z][A-Z][_][F][a][c][t]' --COLLATE SQL_Latin1_General_CP1_CS_AS


IF OBJECT_ID('tempdb..#nameFacts') IS NOT NULL
DROP TABLE #nameFacts;

我不断收到下面的输出，我不希望得到值“CtP_PETER_Fact”。我使用的是 SQL Server 2016 SP2 CU 17。