为什么在Sql数据仓库中，CTE的性能比临时表要好得多？
为什么在Sql数据仓库中，CTE的性能比临时表要好得多？
提问于 2019-12-12 02:50:12
我想从一个大表(大约1千亿行)中选择数据，该表将id与从json传入数据创建的表进行匹配。
下面是我首先做的事情：
SELECT *
#JsonIds
FROM OPENJSON(CONVERT(VARCHAR(MAX), '[{"id": "18897126"},{"id": "710990568"},{"id": "610990568"},{"id": "510990568"}]'))
WITH (id BIGINT);
SELECT *
FROM #jsonIds j
INNER JOIN [schema].[myBigTable] t ON t.id = j.id这一点表现得很糟糕。差不多花了3分钟才完成！
经过几次尝试，我决定看看CTE的表现如何：
WITH JsonIds AS
(
SELECT *
FROM OPENJSON(CONVERT(VARCHAR(MAX), '[{"id": "18897126"},{"id": "710990568"},{"id": "610990568"},{"id": "510990568"}]'))
WITH (id BIGINT)
)
SELECT p.*
FROM [schema].[myBigTable] p
inner join JsonIds j on p.id = j.id令我惊讶的是，CTE做得好多了。花了不到一秒钟的时间。
为什么CTE在这样一个简单的查询上表现得如此之好？
回答 1
Stack Overflow用户
发布于 2019-12-12 09:35:55
尝试向临时表添加统计数据：
SELECT *
INTO #JsonIds
FROM OPENJSON(CONVERT(VARCHAR(MAX), '[{"id": "18897126"},{"id": "710990568"},{"id": "610990568"},{"id": "510990568"}]'))
WITH (id BIGINT);
CREATE STATISTICS StatId on #JsonIds (id);
SELECT *
FROM #jsonIds j
INNER JOIN [schema].[myBigTable] t ON t.id = j.id自动创建统计数据不会在临时表上发生。所以Azure DW可能对临时表的内容做了错误的假设。
如果上述方法都不起作用，那么尝试在每个语句之前加上单词EXPLAIN，并在问题中包含生成的XML解释计划，这样我们就可以看到它在做什么。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/59292225
复制相关文章
相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号