SQL執行計劃是基於模式還是數據或兩者？

我希望這個問題不是太明顯......我已經找到了很多關於解釋執行計劃的很好的信息，但有一個問題我沒有找到答案。SQL執行計劃是基於模式還是數據或兩者？

是當前在數據庫基礎上的模式而已，或者也實際數據計劃（更具體的相對CPU成本）？

我嘗試做在需要我的產品數據庫索引的一些分析，但我與它沒有接近該領域的產品將擁有的數據量我自己的測試系統的工作。我看到一些奇怪的事情，比如在添加索引之後估計的CPU成本實際上略微上升，並且想知道這是否是因爲我的數據集太小。

我正在使用SQL Server 2005和Management Studio來執行計劃

2011-01-24 Rich

有沒有特別的數據庫？他們並不都處理相同的事情。 – 2011-01-24 21:20:33

它將基於架構和數據。模式告訴它哪些索引可用，數據告訴它哪個更好。

答案可以在這取決於你使用的（你沒有說）在DBMS小程度的變化，但他們都保持對索引的統計信息知道的指數是否會有所幫助。如果一個索引將1000行分成900個不同的值，這是一個很好的索引。如果一個索引僅對1000行產生3個不同的值，那麼它不是真的selective，所以它不是很有用。

來源

2011-01-24 21:14:14 RichardTheKiwi

模式和數據都是。

它在構建查詢計劃時使用這些統計信息，使用它們來近似查詢中每個步驟返回的行數（因爲這可能會影響不同類型的聯接的性能等）。

的一個很好的例子是，它不打擾到非常小的表使用的索引，因爲執行表掃描是在這種情況下更快。

來源

2011-01-24 21:13:55

我不能代表所有的RDBMS系統說話，但Postgres的具體使用估計表的大小作爲其努力構建查詢計劃的一部分。例如，如果一個表有兩行，它可以選擇一個順序表掃描JOIN中使用該表的部分，而如果它有10000多行，它可以選擇使用索引或散列掃描（如果）順便提一句，它曾經有可能通過加入VIEWs而不是實際的表格來觸發Postgres中的差勁查詢計劃，因爲沒有估計的VIEWs大小。

的Postgres的如何構造的查詢計劃取決於它的配置文件可調參數部分。有關Postgres如何構建其查詢計劃的更多信息可以在Postgres網站上找到。

來源

2011-01-24 21:16:42 BobG

在計劃之前，VIEW通常在SQL查詢中進行擴展，這就是爲什麼他們不需要統計信息。 – araqnid 2011-01-24 21:43:22

對於SQL Server，有很多因素會影響最終的執行計劃。在基本層面上，統計數據扮演着非常重要的角色，但他們基於數據，但並不總是全部數據。統計數據並不總是最新的。創建或重建索引時，統計數據應基於FULL/100％數據樣本。但是，自動統計刷新的採樣率遠遠低於100％，因此可以對實際上不代表大部分數據的範圍進行採樣。該操作的預計行數也起着一個作用，該作用可以基於表中的行數或過濾操作的統計數據。因此，過時的（或不完整的）統計信息會導致優化器選擇一個不太理想的計劃，就像表中的一些行可能導致它完全忽略索引一樣（這可能會更有效）。

正如在另一個答案中提到的，更獨特的（即選擇性）數據是索引將會更有用。但請記住，唯一有保證統計量的列是索引的前導（或「最左邊」或「第一個」）列。 SQL Server可以並且確實收集其他列的統計信息，甚至一些不在任何索引中，但只有在AutoCreateStatistics數據庫選項被設置（並且是默認情況下）的情況下。

另外，當這些字段在查詢中時，外鍵的存在可以幫助優化器。

但是問題中沒有考慮到的一個方面就是查詢本身。查詢稍有改變但仍然返回相同的結果，可能會有完全不同的執行計劃。也可以通過使用到使用索引無效：

LIKE '%' + field

或在功能包裝領域，如：

WHERE DATEADD(DAY, -1, field) < GETDATE()

現在，請記住，讀操作（理想情況下）索引更快，但DML操作（INSERT，UPDATE和DELETE）更慢（需要更多CPU和磁盤I/O），因爲索引需要維護。

最後，「估計的」CPU等等成本值並不總是依賴於。一個更好的測試是：

SET STATISTICS IO ON 
run query 
SET STATISTICS IO OFF

並專注於「邏輯讀取」。如果你減少邏輯讀取，那麼你應該提高性能。

最後，您將需要一組與生產中的數據相近的數據，以便對索引和查詢本身進行性能調整。

來源

2011-01-24 21:39:07

甲骨文細節：

所陳述的成本實際上是一個估計的執行時間，但它是在計量稍微神祕單元具有與估計的時間做爲塊讀取給出。重要的是要認識到，計算成本對運行時間沒有太多的說明，除非優化器做出的每個估計都是100％完美的（這從來就不是這樣）。

優化程序在決定可以將什麼轉換/啓發式應用於查詢時使用該模式進行很多操作。的模式事情評價xplans時問題很多的一些例子：

外鍵約束（可用於表elimiation）
分區（不包括數據的整個範圍）獨特VS
唯一約束（指數例如範圍掃描）
不空約束（抗連接是不可用未在（）上爲空的列
數據類型（類型轉換，專門日期算術）
Materializ編輯觀點（用於重寫查詢對一個集合）
維的層次結構（以確定函數依賴）
CHECK約束（約束注入，如果它降低了成本）
索引類型（B樹（？），位圖，加盟，功能爲基礎）
列順序在指數（a = 1在{A，B} =範圍掃描，{B，A} =跳躍掃描或FFS）

估算的核心來自使用在實際數據（或熟）上收集的統計數據。統計數據收集用於表格，列，索引，分區，也可能是其他內容。

以下信息被收集：

上午十時正行的表/分區
平均行/列長度
號（成本覈算完全掃描，散列連接，排序，臨時表很重要） col（is_president ='Y'非常獨特）
col中的不同值（last_name不是很唯一）
col中的最小/最大值（幫助無界範圍條件，如date > x）

...幫助估計過濾數據時返回的期望行數/字節數。這些信息用於確定哪些訪問路徑和連接機制可用且適合於給定SQL查詢中與統計信息相比的實際值。

最重要的是，還有物理行順序會影響索引變得「好」或有吸引力與全表掃描的對比。對於索引，這稱爲「聚類因子」，它是衡量行順序與索引條目順序相匹配的度量。

來源

2011-01-24 23:48:42 Ronnis

SQL Server是100％基於成本的優化器。其他RDBMS優化器通常是基於成本和基於規則的組合，但SQL Server無論好壞都完全由成本驅動。基於規則的優化器可能會說，例如，FROM子句中的表的順序決定了連接中的驅動表。 SQL Server中沒有這樣的規則。見SQL Statement Processing：

SQL Server查詢優化器是一個基於成本的優化。根據計算使用的資源量，每個可能的執行計劃的關聯成本爲。查詢優化器必須分析可能的計劃並且選擇具有最低估計成本的計劃。一些複雜的SELECT 語句有數千個可能的執行計劃。在這些情況下，查詢優化器不會分析所有可能的組合。而是使用複雜的算法來查找執行計劃，其成本合理地接近最低可能的成本。

SQL Server查詢優化器確實不會選擇執行計劃具有最低資源成本的 ;它選擇計劃返回結果以合理的成本在資源，並返回結果最快。例如，並行處理查詢通常比使用串行處理更多地使用資源，但是可以更快地完成查詢。 SQL Server優化器將使用並行執行計劃返回結果，如果服務器上的負載將不會受到負面影響。

查詢優化器依賴於當它估計的不同方法的資源費用提取表或索引信息分佈統計。分配統計信息保留爲列和索引。它們指示特定索引或列中的值的選擇性。例如，對於示例，在代表汽車的表中，許多汽車具有相同的製造商，，但每輛汽車具有唯一的車輛標識號（VIN）。 VIN上的索引比製造商的索引更具選擇性。如果索引統計信息不是最新的，則查詢優化程序可能無法爲表的當前狀態選擇最佳的選項。有關保持索引統計信息的更多信息，請參閱 Using Statistics to Improve Query Performance。

來源

2011-01-24 23:59:16

SQL執行計劃是基於模式還是數據或兩者？

回答

相關問題