SQL Server 2005 中 UNION 的性能非常差（未完成）
警告：这是我的系统生成的实际代码：
;WITH RESULTS AS (
SELECT 1174 AS BatchRunID, 'STATINV' AS Program, m.APPL_CD, m.ALBASE, 'CountFocusRecords' AS Measure, COUNT(*) AS Value
FROM [MISWork].[SX_FOCUS_NATIVE_200806] AS m WITH(NOLOCK)
INNER JOIN MISProcess.SXProcessCatalog AS cat WITH(NOLOCK)
ON cat.APPL_CD = m.APPL_CD
AND cat.ALBASE = m.ALBASE
AND COALESCE(cat.ProcessName, 'STATINV') = 'STATINV'
GROUP BY m.APPL_CD, m.ALBASE
UNION
SELECT 1174 AS BatchRunID, 'STATINV' AS Program, c.APPL_CD, c.ALBASE, 'CountBiminiRecords' AS Measure, COUNT(*) AS Value
FROM [MISWork].[SX_STATINV] AS c WITH(NOLOCK)
INNER JOIN MISProcess.SXProcessCatalog AS cat WITH(NOLOCK)
ON cat.APPL_CD = c.APPL_CD
AND cat.ALBASE = c.ALBASE
AND COALESCE(cat.ProcessName, 'STATINV') = 'STATINV'
GROUP BY c.APPL_CD, c.ALBASE
UNION
SELECT 1174 AS BatchRunID, 'STATINV' AS Program, m.APPL_CD, m.ALBASE, 'RecordsInFocusMissingInBimini' AS Measure, COUNT(*) AS Value
FROM [MISWork].[SX_FOCUS_NATIVE_200806] AS m WITH(NOLOCK)
LEFT JOIN [MISWork].[SX_STATINV] AS c WITH(NOLOCK)
ON m.[YEAR] = c.[YEAR]
AND m.[MONTH] = c.[MONTH]
AND m.[BANK_NO] = c.[BANK_NO]
AND m.[COST_CENTER] = c.[COST_CENTER]
AND m.[GLACCOUNT_NO] = c.[GLACCOUNT_NO]
AND m.[CUSTACCOUNT] = c.[CUSTACCOUNT]
AND m.[APPL_CD] = c.[APPL_CD]
AND m.[ALBASE] = c.[ALBASE]
INNER JOIN MISProcess.SXProcessCatalog AS cat WITH(NOLOCK)
ON cat.APPL_CD = m.APPL_CD
AND cat.ALBASE = m.ALBASE
AND COALESCE(cat.ProcessName, 'STATINV') = 'STATINV'
WHERE c.[YEAR] IS NULL
GROUP BY m.APPL_CD, m.ALBASE
UNION
SELECT 1174 AS BatchRunID, 'STATINV' AS Program, c.APPL_CD, c.ALBASE, 'RecordsInBiminiMissingInFocus' AS Measure, COUNT(*) AS Value
FROM [MISWork].[SX_FOCUS_NATIVE_200806] AS m WITH(NOLOCK)
RIGHT JOIN [MISWork].[SX_STATINV] AS c WITH(NOLOCK)
ON m.[YEAR] = c.[YEAR]
AND m.[MONTH] = c.[MONTH]
AND m.[BANK_NO] = c.[BANK_NO]
AND m.[COST_CENTER] = c.[COST_CENTER]
AND m.[GLACCOUNT_NO] = c.[GLACCOUNT_NO]
AND m.[CUSTACCOUNT] = c.[CUSTACCOUNT]
AND m.[APPL_CD] = c.[APPL_CD]
AND m.[ALBASE] = c.[ALBASE]
INNER JOIN MISProcess.SXProcessCatalog AS cat WITH(NOLOCK)
ON cat.APPL_CD = c.APPL_CD
AND cat.ALBASE = c.ALBASE
AND COALESCE(cat.ProcessName, 'STATINV') = 'STATINV'
WHERE m.[YEAR] IS NULL
GROUP BY c.APPL_CD, c.ALBASE
) SELECT * FROM RESULTS ORDER BY Program, APPL_CD, ALBASE, Measure
代码就在那里，没有锁定或阻塞。
UNION 的各个组件都会在几秒钟内返回。 该代码通常用于检查 STAT 组中所有其他程序的输出结果，但仅针对此程序停止。
移除 CTE，没有效果，在那里等待 30 分钟/每小时，无论您想在取消之前等待多长时间。
去掉UNION，11秒返回4个结果集，4个结果集共19条记录。
仅一起运行前两个 - 效果很好，仅一起运行后两个也很好。 前3个在一起也很好。
我已经修改了代码以将它们输出到#temp表，以满足其他要求，所以我只是将其更改为按顺序将每个输出到#temp表，但我从未见过SQL像这样停止没有任何阻止或任何东西的证据。
Warning: this is the actual code generated from my system:
;WITH RESULTS AS (
SELECT 1174 AS BatchRunID, 'STATINV' AS Program, m.APPL_CD, m.ALBASE, 'CountFocusRecords' AS Measure, COUNT(*) AS Value
FROM [MISWork].[SX_FOCUS_NATIVE_200806] AS m WITH(NOLOCK)
INNER JOIN MISProcess.SXProcessCatalog AS cat WITH(NOLOCK)
ON cat.APPL_CD = m.APPL_CD
AND cat.ALBASE = m.ALBASE
AND COALESCE(cat.ProcessName, 'STATINV') = 'STATINV'
GROUP BY m.APPL_CD, m.ALBASE
UNION
SELECT 1174 AS BatchRunID, 'STATINV' AS Program, c.APPL_CD, c.ALBASE, 'CountBiminiRecords' AS Measure, COUNT(*) AS Value
FROM [MISWork].[SX_STATINV] AS c WITH(NOLOCK)
INNER JOIN MISProcess.SXProcessCatalog AS cat WITH(NOLOCK)
ON cat.APPL_CD = c.APPL_CD
AND cat.ALBASE = c.ALBASE
AND COALESCE(cat.ProcessName, 'STATINV') = 'STATINV'
GROUP BY c.APPL_CD, c.ALBASE
UNION
SELECT 1174 AS BatchRunID, 'STATINV' AS Program, m.APPL_CD, m.ALBASE, 'RecordsInFocusMissingInBimini' AS Measure, COUNT(*) AS Value
FROM [MISWork].[SX_FOCUS_NATIVE_200806] AS m WITH(NOLOCK)
LEFT JOIN [MISWork].[SX_STATINV] AS c WITH(NOLOCK)
ON m.[YEAR] = c.[YEAR]
AND m.[MONTH] = c.[MONTH]
AND m.[BANK_NO] = c.[BANK_NO]
AND m.[COST_CENTER] = c.[COST_CENTER]
AND m.[GLACCOUNT_NO] = c.[GLACCOUNT_NO]
AND m.[CUSTACCOUNT] = c.[CUSTACCOUNT]
AND m.[APPL_CD] = c.[APPL_CD]
AND m.[ALBASE] = c.[ALBASE]
INNER JOIN MISProcess.SXProcessCatalog AS cat WITH(NOLOCK)
ON cat.APPL_CD = m.APPL_CD
AND cat.ALBASE = m.ALBASE
AND COALESCE(cat.ProcessName, 'STATINV') = 'STATINV'
WHERE c.[YEAR] IS NULL
GROUP BY m.APPL_CD, m.ALBASE
UNION
SELECT 1174 AS BatchRunID, 'STATINV' AS Program, c.APPL_CD, c.ALBASE, 'RecordsInBiminiMissingInFocus' AS Measure, COUNT(*) AS Value
FROM [MISWork].[SX_FOCUS_NATIVE_200806] AS m WITH(NOLOCK)
RIGHT JOIN [MISWork].[SX_STATINV] AS c WITH(NOLOCK)
ON m.[YEAR] = c.[YEAR]
AND m.[MONTH] = c.[MONTH]
AND m.[BANK_NO] = c.[BANK_NO]
AND m.[COST_CENTER] = c.[COST_CENTER]
AND m.[GLACCOUNT_NO] = c.[GLACCOUNT_NO]
AND m.[CUSTACCOUNT] = c.[CUSTACCOUNT]
AND m.[APPL_CD] = c.[APPL_CD]
AND m.[ALBASE] = c.[ALBASE]
INNER JOIN MISProcess.SXProcessCatalog AS cat WITH(NOLOCK)
ON cat.APPL_CD = c.APPL_CD
AND cat.ALBASE = c.ALBASE
AND COALESCE(cat.ProcessName, 'STATINV') = 'STATINV'
WHERE m.[YEAR] IS NULL
GROUP BY c.APPL_CD, c.ALBASE
) SELECT * FROM RESULTS ORDER BY Program, APPL_CD, ALBASE, Measure
The code just sits there, no locking or blocking.
The individual components of the UNION return in a few seconds each. The code works in general for checking the output results of all the other programs in the STAT group, but just halts for this one.
Remove the CTE, no effect, sits there for 30 minutes/an hour, however long you care to wait before cancelling.
Remove the UNION, and the 4 result sets return in 11 seconds, total of 19 records accross all 4 result sets.
Run just the first two together - works fine, run just the last 2 together, also fine. First 3 together, fine, too.
I've already modified the code to output these to a #temp table, for other requirements, so I'm just going to change it to output each to the #temp table in sequence, but I have never seen SQL just stop like that with no evidence of blocking or anything.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
更改为 UNION ALL，因为您永远不会有重复的情况（“Measure”列被硬编码为不同）。 UNION 必须首先对行进行排序，然后找到重复项并消除。
我真正的猜测是这是一个并行化问题。 尝试在末尾添加 OPTION (MAXDOP 1)。
Change to UNION ALL, since you'll never have dupes (the Measure column is hard coded to be different). UNION must first sort the rows, and then find dupes and eliminate.
My real guess is it's a parallelization issue. Try adding OPTION (MAXDOP 1) at the end.
如果您可以以 XML 格式发布查询执行计划，这将帮助我们确定查询的哪些部分导致了问题。 在 SSMS 中，单击“查询”、“显示估计执行计划”，当它出现时，右键单击它并另存为 XML。
If you can post the query execution plan in XML format, that'll help us determine what parts of the query are causing problems. In SSMS, click Query, Display Estimated Execution Plan, and when it comes up, right-click on it and save as XML.
我已转向回归测试 200808，但基本查询是相同的，具有不同的 batchrunid 和不同的已知良好表。
I've moved on to regression testing 200808, but the fundamental query is the same, with a different batchrunid and different known good table.