sql 查詢優化準則

根據我們的經驗（由很多業界專家證明），在 sql server 上取得的效能提高有 80% 來自對 sql 編碼的改進，而不是來自於對於配置或系統效能的調整。」

—凱文克萊恩等，transact-sql programming 作者

「經驗表明 80%-90% 的效能調優是在應用級做的，而不是在資料庫級」

—托馬斯白特，expert one on one: oracle 作者

可見sql語句對於資料庫效能的重要性。

各種操作符的效率排序：（由高到低） =

like 和 <>都會導致全表搜尋。效率最低。

各種操作符的效率排序：（由高到低）

僅有常量字元（例如 where 1=1 )

僅有列名

僅有引數

多運算元表示式

精確數值型別

其他數值型別

日期型別

字元型別

null

由此可見最有效率的條件查詢查詢是 smallint_column = 1;

where column1 < column2 
and column2 = column3 
and column1 = 5

... where 5 < column2 
and column2 = column3 
and column1 = 5

很顯然表示式2和表示式1是同樣的功能但是效率會高

不過經過研究證明將常量放在表示式的右邊效率要比放在左邊高例如 column > 5 就比 5 > column 效率高。

針對操作符的調優

比如我們有兩個條件用and連線但是如果把概率大條件放在前面的話就會導致第二個and條件被執行的概率大好多，這樣就可能會導致會做多次無用的查詢，所以相對於and條件，應該把概率小條件的放在前面執行。（ps： oracle資料庫是從由到左讀搜尋條件的），而對於or條件，應該把概率大的條件放在最前面，這樣就第二個條件就會更少次數的執行。

儘量減少and和or的出現次數，多用乙個連線條件就等於可能多做一次查詢，優先用and，or條件可能將會導致全表搜尋。

<> like not 等操作符如果可以被別的操作符代替的話最好就不要用。因為用他們進行查詢的時候不會用索引，而且可能導致全部查詢。

例如：where column <> 3 可以被 where colunm >3 or colunm < 3;

比較複雜的情況，根據集合的摩根定理：

not( a and b) = (not a) or (not b) 和 not(a or b) = (not a) and (not b)

in 比多個or要快。

當 in 操作符，是一系列密集的整型數字時，最好是查詢哪些值不符合條件，而不是查詢哪些值符合條件，因此，如下的查詢條件就應該進行如下的轉換：

union 用來合併兩個結果集但是或過濾重複的值，union all則不會過濾重複的值。

查詢 1：

select * from table1

where column1 = 5

union

select * from table1

where column2 = 5

查詢 2：

select distinct * from table1 
where column1 = 5 
or column2 = 5

在上面的例子中，column1 和 column2 都沒有索引。如果查詢 2 總是比查詢 1 執行的快的話，那麼就可以建議總是將查詢 1 轉換成查詢 2，但是有一種情況，這樣做在一些資料庫系統中可能會帶來效能變差，這是由於兩個優化缺陷所造成的。

第乙個優化缺陷就是很多優化器只優化乙個 select 語句中乙個 where 語句，所以查詢 1 的兩個 select 語句都被執行。首先優化器根據查詢條件 column1 = 5 為真來查詢所有符合條件的所有行，然後據查詢條件 column2 = 5 為真來查詢所有符合條件的所有行，即兩次表掃瞄，因此，如果 column1 = 5 沒有索引的話，查詢 1 將需要 2 倍於查詢 2 所需的時間。如果 column1 = 5 有索引的話，仍然需要二次掃瞄，但是只有在某些資料庫系統存在乙個不常見的優化缺陷卻將第乙個優化缺陷給彌補了。當一些優化器發現查詢中存在 or 操作符時，就不使用索引查詢，所以在這種情況下，並且只有在這種情況下，union 才比 or 效能更高。這種情況很少見，所以仍然建議大家當待查詢的列沒有索引時使用 or 來代替 union。

sql 查詢優化準則

查詢優化 SQL優化

查詢優化 sql

優化sql查詢

sql 查詢優化準則

查詢優化 SQL優化

查詢優化 sql

優化sql查詢

相關推薦