Question

我已经看过这个：The Same SQL Query takes longer to run in one DB than another DB under the same server但是我仍然对此感到困惑。我已在两个数据库上测试了这个，拥有完全相同的查询计划，但在测试数据库上，此查询在20ms内运行，而在开发数据库上，这需要1分钟。

需要注意的是，测试数据库是当前时间点开发数据库的IDENTICAL副本（请注意，自提出此问题以来已经发生了轻微的架构更改 - 请参阅编辑以获取更多信息）。我正在运行的查询是：

SELECT 
    pn.PARTNO,
    LogisticsComment,
    Length,
    Width,
    Height,
    Weight 
FROM [partDB] pn
INNER JOIN [storeLines] sl
ON pn.PARTNO = sl.PARTNO
INNER JOIN [storeRequests] sr
ON sl.ITEMID = sr.LINEITEMS
WHERE sr.SERIAL = 'S14566'

这是查询执行计划：

我不知道是什么原因引起的。另外需要注意的是，链接的问题有200万条记录 - 这个查询目前应该返回26条记录。

编辑：对延迟道歉，生活有抛出曲线球的习惯。

根据要求，请查找实时和测试系统的XML。

开发： PasteBin link

测试： PasteBin link

实时和测试系统的实际执行计划：

开发：

测试

修改2 ：我已完成架构比较，并注意到此查询中的两列，＆＃39; TMTPARTNO＆＃39;和＆＃39;后勤评论＆＃39;具有不同的数据类型 - 在测试系统中，它们分别是varchar（50）和nvarchar（1500），在实时系统中，它们是char（18）和nchar（1500）。在不改变实时系统中的数据类型的情况下，我想知道性能影响是否可能是因为有很多字节被用于物流评论＆＃39;场？

Answer 1

在问题的开头，您谈论的是测试与开发数据库;稍后你会参考Test vs Live。这很令人困惑。

查看两个执行计划时都会出现警告：

Live - Cardinality Estimate Expression="CONVERT_IMPLICIT(nchar(18),[pn].[PartNumber],0)"

Test - Cardinality Estimate Expression="CONVERT_IMPLICIT(nvarchar(50),[pn].[PartNumber],0)"

两个数据库中的字段pn.PartNumber和sl.PartNumber的类型是什么？

显然他们在两种情况下都不匹配，这是不好的。可能在一种情况下，不匹配会导致更严重的后果。估计的行数略有不同（3对4），实际返回行数为26.

计划的另一个不同之处：

实时计划使用名为STORES-REQ-LINK的{{1}}上的索引。

测试计划使用名为STORES-REQ-LINK_SerialIndex的{{1}}上的索引。

这些索引是否相同？

表基数略有差异：110077对106488,97535对92892，这解释了估计行数的微小差异。

因此，数据库在结构和实际数据方面都不相同。让它们相同并再次比较性能是有意义的。

说完这一切之后，你的表不大（~100K行），所以这种查询不应该花费几分钟。

这两个数据库位于同一台服务器上，因此CPU和内存应该相同。它们位于相同的硬盘上吗？

尽管如此，计划非常相似，查询处理的实际数据量很小（77KB对39KB），因此这种性能的巨大差异很可能是由于某些阻塞/锁定造成的。慢查询可能只是在等待某些资源。你对这两个数据库都有什么样的活动？

查询一台服务器上

1 个答案: