如果在关系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将使用此时找到的最佳计划。
总之，很少有语句被优化，很少没有
当然不。大多数时候，这将是最好的方式之一，但总是最好的？不可以。优化器必须处理应用于包含任何数据的任何模式的任何语句。具有完全相同逻辑的两个不同查询（总是响应相同的数据结果）可能具有不同的执行计划。
对于非平凡的查询，它很可能不会为您提供最优化的执行计划。一个原因是找到最佳的优化查询重写是一个难以解决的问题。例如，成本最小化的连接排序被认为是np-hard（来自n个节点的可能生成的树的数量是n ^（n-2）Cayley's formula），并且成本函数是启发式的（基于诸如基数，稀疏性，存储的属性）模型等...）。连接排序只是连接优化工作的一个子集，它本身就是整个查询优化工作的一个子集。