pro*_*r08 16 performance sql-server sql-server-2012
我将大型网站和数据库从旧服务器（Windows 2008 / SQL Server 2008 / 16 GB RAM / 2 x 2.5 GHz 四核 / SAS 磁盘）迁移到更新、更好的服务器（Windows 2008 R2 / SQL Server 2012 SP1 / 64 GB RAM / 2 x 2.1 GHz 16 核处理器 / SSD 磁盘）。
我分离了旧服务器上的数据库文件，将它们复制并附加到新服务器上。一切都很顺利。
之后，我将兼容级别更改为 110，更新统计信息，重建索引。
令我非常失望的是，我注意到大多数 sql 查询在新的 SQL 2012 服务器上比在旧的 SQL 2008 服务器上慢得多（慢 2-3-4 倍）。
例如，在一个包含大约 70 万条记录的表上，在旧服务器上查询索引需要大约 100 毫秒。在新服务器上，相同的查询大约需要 350 毫秒。
所有查询都会发生同样的情况。
我会很感激这里的一些帮助。让我知道要检查/验证的内容。因为我发现很难相信在具有更新 SQL Server 的更好服务器上，性能会更差。
更多细节：
内存设置为最大。
我有这个表和索引：
CREATE TABLE [dbo].[Answer_Details_23](
[ID] [int] IDENTITY(1,1) NOT NULL,
[UserID] [int] NOT NULL,
[SurveyID] [int] NOT NULL,
[CustomerID] [int] NOT NULL default 0,
[SummaryID] [int] NOT NULL,
[QuestionID] [int] NOT NULL,
[RowID] [int] NOT NULL default 0,
[OptionID] [int] NOT NULL default 0,
[EnteredText] [ntext] NULL,
CONSTRAINT [Answer_Details_23_PK] PRIMARY KEY NONCLUSTERED
(
[ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
CREATE NONCLUSTERED INDEX [IDX_Answer_Details_23_SummaryID_QuestionID] ON [dbo].[Answer_Details_23]
(
[SummaryID] ASC,
[QuestionID] 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) ON [PRIMARY]
我执行了这个查询：
set statistics time on;
select summaryid, count(summaryid) from Answer_Details_23 group by summaryid order by count(summaryid) desc;
set statistics time off;
旧服务器 - SQL Server 执行时间：CPU 时间 = 419 毫秒，已用时间 = 695 毫秒。
新服务器 - SQL Server 执行时间：CPU 时间 = 1340 毫秒，已用时间 = 1636 毫秒。
执行计划上传到这里：http : //we.tl/ARbPuvf9t8
稍后更新：
现在，SQL Server 执行时间：CPU 时间 = 550 毫秒，经过时间 = 828 毫秒。
它仍然比旧服务器差，但还不错。如果您有任何其他建议（本地查询优化除外），请随时发表评论。
让我知道要检查/验证的内容
你有性能问题。遵循诸如等待和队列之类的性能故障排除方法来确定瓶颈。链接的方法向您展示了测量什么以及如何测量。在此处发布调查结果，我们可以根据您的实际测量结果提供具体建议。因为它太开放了，这是任何人的猜测。将其缩小到特定问题将消除猜测。
更新后
计划完全不同。旧计划在堆栈上有一个低流聚合，它实际上有一个糟糕的基数估计（141k 对 108k）和散列数学进一步错误预测，相反（35k 对 108k）。新计划没有流聚合，并且一直到顶部都有准确的估计。当然，这并不能解释为什么旧计划执行得更快。
底部扫描的行数略有不同（不显着），但成本却大不相同：旧的 2.49884 (IO 2.28979 CPU 0.20905) 与新的 1.59109 (IO 1.53868 CPU 0.0524084)。再次指向 2012 年更好的执行（索引重建可能减少了碎片？）。
非常不同的是线程的数量：新的 32 个（每个获得 ~23k 行）与 8 个旧的（每个获得 ~95k 行）。桌子相当窄。这可能是在大量线程的实际伤害，因为很多更加频繁的性能缓存废票。我会尝试：
注意到你的评论：
使用 maxdop 8 查询添加执行计划实际上更快
这可能只是 CPU 互相踩踏。SSD 到位后，IO 可能几乎没有，因此该表绝对太小，无法保证 32 个扫描仪。该交换交换可能会不断使 L1/L2 失效。
小智 8
我在 SQL Server 上遇到过类似的问题，可能是您的服务器没有优化配置。较新的 Xeon 带有 TurboBoost、HT 等，可以显着影响服务器性能。
例如，我们已经取得了成功； 戴尔服务器的低延迟配置
这些设置将适用于非戴尔服务器，只是它们的名称可能不同。
我们还通过将 Windows 电源管理配置文件从 Balanced 设置为高性能来提高性能。最后一点是，建议为 x64 服务器上的操作系统保留最多 8GB 的内存，默认 SQL 安装会占用所有内存。您可能希望通过将最大 SQL Server 内存配置设置为比总内存少 4/8GB 来尝试 4/8GB 预留。
如果可能，我的建议是恢复到旧服务器。如果您没有可用的回归/自动化/加载脚本，那么您能做的最好的事情就是在高活动期间记录 1-4 小时的系统活动。然后设置一个与生产相同的 Web 服务器，以及一台客户端机器来运行脚本。对新服务器运行相同的活动，更改配置并再次运行相同的活动。确实，您会想要做更多的事情，但它似乎不可行并且超出了这个问题的范围。