我有以下表格的查询
exec sp_executesql N' UPDATE table SET column1 = 1, modify_date=N''2020-02-12 04:55:59.000'' WHERE (column5=@P1 AND column6=@P2 )',N'@P1 nvarchar(36),@P2 int',N'458986156148',87
我无法更改有关此查询本身的任何内容。它来自应用程序。
每次执行时，更新值都会发生变化，从而导致生成新的查询计划，而不是重用以前的计划。
强制参数化已打开，但似乎对此查询没有影响，可能是它的执行方式。
执行查询本身时，我看到更新总共有 4 次读取。在这种情况下，执行本身不会导致更新，因为 where 子句没有返回任何行。
使用分析器，我看到查询进入和开始之间的时间几乎是查询的整个时间（1 秒）。实际执行几乎是立即的。
分析器显示 455.000 次读取！查询执行本身没有显示。
所以现在我想知道
- 我可以强制查询在这里使用相同的计划吗？计划指南似乎仅可用于同一查询或受强制参数化影响的查询。
- 我们可以提高这个查询的编译速度吗？455.000 次读取从何而来？该表上有很多统计数据（+- 100），但 455.000 次读取似乎相当多。
这是在 SQL Server 2019 上，还没有累积更新。我扫描了 CU 更改日志以查找可能与此有关的任何内容。
编辑/进一步调查显示在编译期间其他表上有很多锁。我有 300 个表，它们的外键引用了我要插入的表中的主键。
所有外键关系都是可信的。在编译阶段有什么方法可以防止这些检查吗？
编辑 2/ 依赖项不是外键约束，而是表上的视图。使用该表的所有视图在执行期间都具有 SCH-S 锁，这是预期的。目前尚不清楚这是否也导致读取...
编辑 3/ 显然 455.000 次读取是通过扫描 sys.sysmultiobjrefs 系统表超过一百万次完成的。这似乎不是正确的行为。
没错，强制参数化在这里不起作用，因为查询“已经在客户端应用程序上进行了参数化”（source）。也就是说，问题在于实际参数有两个，所以不能强制嵌入date和int参数。
关于读取/ CPU 发生了什么......
自动创建/更新的统计信息
就分析器中显示的读取而言，这些确实包括统计更新和创建。如果它只是偶尔发生，那将解释这个问题。 由于您提到每次执行时都会出现这些长编译时间和高读取，这似乎不是罪魁祸首（除非这个应用程序正在做一些非常不寻常的事情，比如积极地删除自动统计信息）。
版本存储读取
还有其他类型的阅读没有报道，我在博客上
SET STATISTICS IO ON谈到了。这些包括版本存储读取，因此如果您在此数据库上启用或启用，则可以解释一些 CPU / 读取差异。特别是如果您有长时间运行的事务。SNAPSHOTREAD COMMITTED SNAPSHOT其他故障排除
如果您可以在重现问题时为相关查询共享“实际执行计划”，这可能会有所帮助。除了您已经提供的信息之外，可能还有一些线索。
计划强迫
据我所知，没有任何方法可以防止每次出现这些查询之一时编译计划（正如您所指出的，计划指南不起作用，查询存储计划强制也不起作用）。
临时工作负载
optimize for ad hoc workloads附带说明一下，由于您拥有这些嵌入式参数，因此您的工作负载可能会从服务器级配置选项中受益匪浅。它将防止您的计划缓存变得臃肿，这也可能导致 CPU 问题（因为 SQL Server 必须随着时间的推移从计划缓存中逐出项目，因为每个查询都会出现所有“新”计划）。我们有一个变通方法，简而言之，查询编译期间的绑定阶段花费的时间最长，并且在删除表上视图的 SCHEMABINDING 属性时消失了。
查询存储信息表明查询编译时间主要用于绑定而不是优化或解析。
虽然目前尚不清楚这是错误还是预期行为，但读取是在 sys.sysmultiobjrefs 表上完成的。该表根据文档“存在于每个数据库中。包含每个常规 N 到 N 引用的一行”。查看值时，它还包含表上的（非索引）视图。我们要插入记录的表有大约 3000 个视图。
删除视图时，编译时间线性下降。当然，我们无法删除视图并阻止绑定阶段检查视图，我已经删除了该表上视图的 SCHEMABINDING 属性。查询编译和插入现在减少到毫秒而不是 1-2 秒。
当然，我们需要考虑应用程序未来升级期间的影响。