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優化工作的一個子集，它本身就是整個查詢優化工作的一個子集。