版本 sql查詢優化 臨時 dash 沒有 多表 測試 最小 問題

查詢時，如果數據量很大，where 後面的條件與建索引的順序相同，也沒有什麽多少差別，聚集索引稍微快點; 但where 後面的條件與建索引順序不同，速度會慢下來，到底慢多少，不同的機器會不一樣，沒有絕對的說法。

MSSQL引擎首先對條件進行優化，優化以後再查詢。
1，還是那句，先看執行計劃。
2.2008的話，對where的順序它會自己優化，測試過，順序對執行計劃沒有影響，不過2005好像有。所以從規範化來說，還是把篩選性高的放在where的前面，而不是考慮是否聚集索引
3.對於建立索引，就有講究了，統計信息只看索引的第一列，所以創建索引時，篩選性高的那列應該放到索引定義的第一位。

#1.WHERE後面的條件只要一模一樣，寫在哪兒都是無所謂的。相同環境下，生成的執行計劃也是一樣的。

#2.至於建立索引的順序，就有講究了：1.復合索引的第一個字段最重要，SQL SERVER只生成復合索引第一個字段的統計信息，那麽優化器也只能根據復合索引的第一個字段的統計信息來優化查詢。2.當你自己從業務上了解了數據分布後，怎樣寫SQL和怎樣建立索引就是一門學問了。有時候要根據SQL語句建立索引，有時候要根據已有索引更改SQL語句（用臨時表等方法）。
#3.要想學會創建適合業務的索引，除了業務中的數據分布，你要了解索引的結構（聚集和非聚集），高選擇性的概念，數據在頁上的存儲方式，及看得懂執行計劃。

sp_help ‘表名‘，拉到最下，有索引的定義

--指的fieldA,fieldB的順序,也就是說：把fieldA這個字段排在第一位,是要考慮考慮的

CREATE INDEX IX_tablename_fieldA_fieldB ON dbo.tablename
(
FieldB
)
GO

索引順序有講究，where一般沒有，不過2005及以下版本聽說是有的，不過我沒環境，你最好試一下

1、那個是符合索引。
2、所謂的索引順序，其實是復合索引的順序，兩個索引之間沒啥順序可言，具體由sql查詢優化器去根據統計信息及查詢語句，和當前資源，選擇使用哪個索引而已。

1、程序端的sql語句中，mssql對where的順序會優化。不存在“ 1=1 ”的問題；也不存在“聚集 and 非聚集”的順序問題。
2、mssql表中的索引順序，對查詢效率有影響，具體的需要結合實際業務——能夠將查詢結果最小化的索引放置在前面。

（個人見解——其實大多數業務中，應該是主鍵—聚集索引—非聚集索引）
3、符合索引的“字段A、字段B”——不說了，這個清楚。

主鍵僅僅為了確保業務上的數據可標識性，實際上可以沒有聚集索引（我就改過很多表，把主鍵上的聚集索引移到別的字段上，效果不錯），但是很多業務又真的需要經常使用主鍵做一些適合聚集索引特性的操作，所以可能這也是微軟默認把主鍵帶有聚集索引的理由之一，而且聚集索引能組織數據。對性能和維護來說很重要

where條件順序與建索引順序