SQL Server優化

是否有人能夠提供有關SQL Server能夠進行哪些優化的信息？我使用的是2005年的標準版，有時也和2008年一起工作。 2008能夠執行2005年不能查詢的優化嗎？SQL Server優化

有時候我會運行一個查詢，這將需要很長時間沒有明顯的原因，我必須用不同的方法重寫它。（CTE而不是子查詢等）我想提前知道在開始使用SQL服務器之前SQL服務器是否會爲查詢提供最佳或接近可選的性能。

加入到子查詢

select ... from tbl1 left join(
    select ... from tbl2 group by ... 
) as subQ on t1.pk = subQ.fk 
where t1.pk between 50 and 100

如果我加入一個表的子查詢同上，結果集進行過濾，我可以期待WHERE子句中過濾下來所有 SQL服務器進行傳播相關的子查詢？編譯器在確定結果集的哪些部分最終將用於最終輸出中有多好？

很多組列由

子查詢與分組依據，往往可以寫成一個直線上升加盟，但隨後被

select tbl1.pk,b,c,d,e,f,g, sum(tbl2.h) from tbl1 
inner join tbl2 on tbl1.pk = tbl2.fk 
inner join tbl3 on tbl1.fk = tbl3.pk 
group by tbl1.pk, tbl1.b, tbl3.c, tbl3.d, tbl3.e, tbl3.f, tbl3.g

每個引用組中的許多列是必要的除表3中的一行外，表1中的行將與表2中的多行相匹配。（注意與表3的pk的連接）由於此原因，組中除tbl1.pk之外的所有列都是多餘的。但是，SQL要求無論如何都要在組中使用它們。現在優化器應該只是在表1的主鍵上進行排序，以便聚合表2中的行。它會這樣做，還是會不必要地對組中的整個列集進行排序和比較？如前所述，另一種方法是將表2聚合到子查詢中，然後再回到表1和表3中。這是否有所不同？

來源

2012-03-18 Trent

是2008能夠進行額外的優化。

其中一個指標是sys.dm_exec_query_transformation_stats在我的2008實例上有390個可能的轉換，在我的2005實例上有380個轉換（關於此DMV的一些解釋here）。

一般來說，差異是進化改善，但不是顯着。我從自己的經歷中發現，在Connect上報告次要性能問題時，他們傾向於修復下一個版本，而不是回溯到以前的版本（e.g. 1,e.g. 2）

我知道有幾個領域在2008年有所改進正在處理partitioned tables，當使用OPTION (RECOMPILE)計劃時，查詢計劃爲dynamic search conditions，在Views中使用predicate pushing。

關於您提出的具體情況，您需要檢查兩個版本中的執行計劃，以瞭解您是否可以辨別策略中的任何差異。

來源

2012-03-18 23:05:16

謂詞推送示例指示問題出現在視圖中，但與表值函數不同。在這種情況下，使用（非索引）視圖是否有意義？表函數似乎沒有任何缺點。 – Trent 2012-03-20 13:29:11

@Trent - 您無法在TVF或呼叫端創建觸發功能（例如'NEWID（）'）。如果你不需要那些，那麼不需要。不AFAIK。 – 2012-03-20 13:38:31

「有時我會運行一個查詢，它會花費大量的時間沒有明顯的原因」 - 我會調查重寫查詢之前的實際原因。

通常情況下，由於過期的統計信息或索引需要重新構建或缺少索引，因此原因是不適當的緩存查詢計劃。

這是標準基準：Slow in the Application, Fast in SSMS?

至於你的發言：「我想知道提前SQL服務器是否要給我最佳的或接近可選的性能從查詢之前，我開始使用它「 - 最佳往往是相對的。 SQL Server使用統計信息和基於成本的優化器來確定查詢計劃。通常，您必須針對正常運行的查詢工作負載進行優化，而不是針對單個查詢。該SQL Server 2008有

一種優化是優化即席查詢工作負載（如奧姆斯產生的那些）的能力：Plan cache and optimizing for adhoc workloads

[BTW：對於SQL私人MVP排行榜上談到，即使服務器，優化器在特定情況下的運行方式並不總是受到產品團隊的推崇。有可能推斷出一些，但它可以在更新之間變化。]

來源

2012-03-18 04:07:54

回答

相關問題