DBMS优化器-最佳执行计划,无论查询形式如何 [英] DBMS optimizer - best execution plan, no matter the query's formulation

查看:51
本文介绍了DBMS优化器-最佳执行计划,无论查询形式如何的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

如果在关系DBMS中编写查询Q,优化器不会选择执行它的最佳方式(取决于多个因素)吗?不管您如何表示Q,优化器都不会选择最好的方式来执行它吗?我对SQL Server和Oracle很好奇。

例如,设Q为:

SELECT * 
FROM t1, t2
WHERE t1.some_column = t2.some_column

如果存在正确的索引(具有正确的选择性),我们应该会看到索引查找,后面可能是键查找。我们不会看到执行计划中的交叉积后跟选择。

那么,为什么https://technet.microsoft.com/en-us/library/ms189575(v=sql.105).aspx声明"在Transact-SQL中,包含子查询的语句和不包含子查询的语义等价版本之间通常没有性能差异。但是,在某些必须检查是否存在的情况下,联接会产生更好的性能。"无论您如何编写查询Q,无论Q的查询类是什么(SPJ、SPJ+UNION、SPJ+子查询等),优化器都不会找到语义等价的最佳版本吗?

谢谢!

推荐答案

无论如何计算Q,优化器都不会选择最佳的执行方式(取决于多个因素)吗?

我想引用本书中的Itzik Ben-Gan的话:Microsoft SQL Server 2012 High-Performance T-SQL Using Window Functions

这有几个原因。

首先,SQL Server的优化器并不完美。我不想 听起来不屑一顾-SQL Server的优化器真的是一个奇迹,当你想到这一点的时候 软件构件可以实现。但事实是,它并没有进行所有可能的优化 其中编码的规则。

第二,优化器必须限制花在优化上的时间;否则,它优化查询的时间可能比时间长得多 优化从查询的运行时间中减去。

这种情况可能和在几十毫秒内生成一个计划一样荒谬,而没有检查所有可能的计划,运行时间只有几秒钟,但是生成所有可能的计划希望减少几秒钟可能需要一年甚至几年的时间。您可以看到,由于实际原因,优化器需要限制花在优化上的时间。

根据查询中涉及的表的大小等因素,SQL Server计算两个值:一个是考虑到的成本- 边缘 足够好了 对于查询,另一个是要花费的最大时间量 停止前的优化。如果达到任一阈值,优化将停止,并且SQL Server 使用在该点找到的最佳计划。

总而言之,经过优化的语句很少,没有优化的语句很少

这篇关于DBMS优化器-最佳执行计划,无论查询形式如何的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆