读取表变量的查询可以在 SQL Server 2008 中生成并行执行计划吗?
首先,来自 BOL:
修改表变量的查询不会生成并行查询执行计划。修改非常大的表变量或复杂查询中的表变量时,性能可能会受到影响。在这些情况下,请考虑使用临时表。有关详细信息,请参阅创建表 (Transact-SQL)。读取表变量而不修改它们的查询仍然可以并行化。
这似乎很清楚了。 读取表变量而不修改它们的查询仍然可以并行化。
但随后在 SQL Server 存储引擎,一个其他信誉良好的来源,Sunil Agarwal 在 2008 年 3 月 30 日关于 tempdb 的一篇文章中这样说道:
涉及表变量的查询不会生成并行计划。
Sunil 是否解释了 BOL re: INSERT,或者 FROM 子句中表变量的存在是否妨碍了并行性?如果是这样,为什么?
我特别考虑控制表用例,其中您有一个小的控制表连接到一个更大的表,以映射值,充当过滤器,或两者兼而有之。
谢谢!
First, from BOL:
Queries that modify table variables do not generate parallel query execution plans. Performance can be affected when very large table variables, or table variables in complex queries, are modified. In these situations, consider using temporary tables instead. For more information, see CREATE TABLE (Transact-SQL). Queries that read table variables without modifying them can still be parallelized.
That seems clear enough. Queries that read table variables, without modifying them, can still be parallelized.
But then over at SQL Server Storage Engine, an otherwise reputable source, Sunil Agarwal said this in an article on tempdb from March 30, 2008:
Queries involving table variables don't generate parallel plans.
Was Sunil paraphrasing BOL re: INSERT, or does the presence of table variables in the FROM clause prevent parallelism? If so, why?
I am thinking specifically of the control table use case, where you have a small control table being joined to a larger table, to map values, act as a filter, or both.
Thanks!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
好的,我有一个并行选择,但不是在表变量上,
我已将其匿名化并且:
查询 + 计划:
现在,考虑一下,表变量几乎总是表扫描,没有stats 并假设一行“估计行数 = 1”,“实际.. = 3”。
我们可以声明表变量不并行使用,但包含计划可以在其他地方使用并行性吗?所以 BOL 是正确的,而 SQL Storage 文章是错误的
OK, I have a parallel select but not on the table variable
I've anonymised it and:
Query + plan:
Now, thinking about it, a table variable is almost always a table scan, has no stats and is assumed one row "Estimated number of rows = 1", "Actual.. = 3".
Can we declare that table variables are not used in parallel, but the containing plan can use parallelism elsewhere? So BOL is correct and the SQL Storage article is wrong
显示表变量本身的并行运算符的简单示例。
Simple Example showing a parallel operator on a table variable itself.
[在这里回答我自己的问题,以便我可以适当地提出相关引用......]
Boris B,来自 线程:
并且:
据我所知,表变量不是 B,可能是 A。
另一个相关引用,回复:非内联 T-SQL TVF :
[Answering my own question here, so I can present the relevant quotes appropriately....]
Boris B, from an thread at MSDN SQL Server forums:
and:
As best I can tell, table variables are not B and may be A.
Another relevant quote, re: non-inlined T-SQL TVFs:
我的理解是,对于 UPDATE/DELETE/INSERT 操作,并行性在表变量上被阻止,但对于 SELECT 则不会。当然,证明这一点比仅仅假设要困难得多。 :-)
My understanding is that parallelism is blocked on table variables for UPDATE/DELETE/INSERT operations, but not for SELECTs. Proving that would be a lot more difficult than just hypothesizing, of course. :-)