很奇怪，这很不幸，这超出了我的技术水平。我们有一个相当大的数据库（35GB），使用率中等。这是在较旧的硬件和SQL Server 2008上安装的。我们有了一个新服务器，有更多的RAM /更快的处理器-太棒了！硬盘设置相同（即RAID /配置/文件位置）。备份数据库并在新服务器上还原（以2012模式运行）。一切似乎都很好-但一切都不好。我遇到了非常奇怪的性能问题。大多数查询的运行速度略快，这很好，但是第一次运行时某些查询的速度慢得多。
示例-我们有一个查询，初始运行需要7秒才能完成。如果我再次运行它，则需要250毫秒。如果更改参数值，则需要7秒钟才能再次运行。如果清除查询计划缓存，则需要7秒钟才能再次运行。如果我在旧数据库上运行相同的查询，则第一次运行需要500毫秒，第二次运行需要400毫秒。
因此，编译查询所花费的时间有所增加。当我返回实际的执行计划时，它是相同的，但是新服务器上的估计行数/子树成本要高得多。当我执行属性并获取编译时间时，旧服务器上的编译时间是7000 vs 350（假设多数民众赞成是ms）。
如果我修改查询并具有options（recompile），则每次都要花3秒的时间来运行。初始速度如此之快，但召回速度仍然太慢。
作为迁移的一部分，重建了所有索引并更新了统计信息。
长话短说，新服务器更快，但是只有在创建查询计划之后。想法？
不包含任何代码，因为查询不是问题-在SQL Server 2008上运行良好，在首次运行后在2012年运行良好。 [编辑-我所说的变量示例。在两次编辑之间，我只是将“某物”更改为“某物1”]
DECLARE @myReference VARCHAR(50) = 'something'
SELECT Column1, Column2
FROM dbo.Table
WHERE Column3 = @myReference
[/编辑]
我希望由于硬件更好，总体性能会比2008年有所改善。
探查器输出的图像：[探查器]：https://imgur.com/hq5t73t“探查器图像”
Confirmation of version: Microsoft SQL Server 2012 (SP4) (KB4018073) -
11.0.7001.0 (X64) Aug 15 2017 10:23:29 Copyright (c) Microsoft Corporation Standard
Edition (64-bit) on Windows NT 6.2 <X64> (Build 9200: )
答案 0 :(得分：0)
显然，问题出在高编译时间上。
也许此问题已由MS解决并解决。
服务器是否已更新到最新的Service Pack和累积更新？ 是否启用了跟踪4199？要启用的SQL：
DBCC TRACEON (4199, -1)
大量的统计信息（尤其是自动创建的统计信息）可能会导致编译时间过长。删除其中一些会调整编译时间吗？
也可以通过强制参数化来防止重新编译：
ALTER DATABASE [your db] SET PARAMETERIZATION FORCED
但是，它可以改善当前有问题的查询，而其他一些查询则会受到参数嗅探的困扰。