DBMS 优化器 - 最佳执行计划，无论查询的公式如何

Question

如果在关系型 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 + 子查询等），优化器不会找到最好的语义等效版本吗？

谢谢！

Answer 1

无论如何制定 Q，优化器都不会选择执行它的最佳方式（取决于多种因素）？

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

有几个原因。

一方面，SQL Server 的优化器并不完美。 我不想听起来不屑一顾——当您想到该软件组件可以实现的功能时，SQL Server 的优化器确实是一个奇迹。 但事实上，它并没有编码所有可能的优化规则。

二、优化器必须限制优化花费的时间； 否则，与优化从查询的运行时间中节省的时间相比，它可能花费更长的时间来优化查询。

这种情况可能就像在几十毫秒内生成一个计划一样荒谬，而没有遍历所有可能的计划并且只获得几秒钟的运行时间，但是生成所有可能的计划以希望缩短几秒钟可能需要一年时间甚至几个。 您可以看到，出于实际原因，优化器需要限制优化所花费的时间。

基于查询中涉及的表的大小等因素，SQL Server 计算两个值：一个是被认为足以满足查询的成本，另一个是停止前用于优化的最长时间。 如果达到任一阈值，优化将停止，并且 SQL Server 使用此时找到的最佳计划。

总而言之，优化的语句很少，没有优化的语句

Answer 2

当然不。 大多数时候它是最好的方法之一，是的，但总是最好的？ 不可以。优化器必须处理应用于任何模式的任何语句，其中包含任何数据。 具有完全相同逻辑（始终响应相同数据结果）的两个不同查询可能会有不同的执行计划。

Answer 3

对于非平凡的查询，它很可能不会为您提供最优化的执行计划。 一个原因是找到最佳优化查询重写是一个 np-hard 问题。 例如，成本最小化的连接排序被认为是 np-hard（从 n 个节点可能生成的树的数量是 n^(n-2) Cayley's formula ），成本函数是启发式的（基于基数、稀疏性、存储模型等...）。 而join ordering只是join优化工作的一个子集，它本身就是整个查询优化工作的一个子集。