sql-server - 一台服务器上两个数据库的查询性能

Question

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

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

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: 我进行了架构比较并注意到此查询中的两个列“TMTPARTNO”和“LogisticsComment”具有不同的数据类型 - 在测试系统中，它们分别是 varchar(50) 和 nvarchar(1500)，在 live 系统中，它们是 char(18) 和 nchar(1500)。在不更改实时系统中的数据类型的情况下，我想知道性能影响是否可能在于“LogisticsComment”字段使用了这么多字节这一事实？

Answer 1

在问题的开头，您谈论的是测试数据库与开发数据库；稍后你会提到测试与现场。这令人困惑。

在查看两个执行计划时会出现警告:

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 上的索引，称为 STORES-REQ-LINK_SerialIndex。

测试计划使用名为 STORES-REQ-LINK_Index02122015 的 STORES-REQ-LINK 索引。

这些索引是否相同？

表基数存在细微差异:110077 与 106488、97535 与 92892，这解释了估计行数的细微差异。

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

说了这么多，您的表并不大(约 100K 行)，所以这种查询应该不会花费几分钟。

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

尽管如此，计划非常相似，查询处理的实际数据量很小(77KB 对 39KB)，因此性能上的这种巨大差异很可能是由某些阻塞/锁定引起的。慢速查询很可能只是在等待一些资源。您在这两个数据库上有哪些事件？