1. 選擇最有效率的表名順序, FROM子句中寫在最後的表(基礎表 driving table)將被最先處理，在FROM子句中包含多個表的情況下,你必須選擇記錄條數最少的表作為基礎表.汗顏！！以前以為dimensional table,都是多條記錄呢，怪不得以前寫的查詢速度這麼慢。
e子句中的連線順序．：
資料庫採用自下而上的順序解析Where子句,根據這個原理,表之間的連線必須寫在其他Where條件之前, 那些可以過濾掉最大數量記錄的條件必須寫在Where子句的末尾NG最後。這個貌似一直這麼寫的，不過那是在SQLSERVER裡面的，前面都是用的JOIN
3.整合簡單,無關聯的資料庫訪問：
如果你有幾個簡單的資料庫查詢語句,你可以把它們整合到一個查詢中(即使它們之間沒有關係)，這個我沒有體會，貌似都是按照業務邏輯把它們分成了一小塊一小塊的呢
4.儘量縮小子查詢的結果。
5.用EXISTS替代IN、用NOT EXISTS替代NOT IN。貌似我做專案的時候只在少數基於條件的表連線才會用EXISTS，基本不用IN 和NOT IN。
6.避免在索引列上使用計算．
Where子句中，如果索引列是函式的一部分．優化器將不使用索引而使用全表掃描． 7，用>=替代> 這個我也不是特別明白，>是IS NOT？
8，用UNION替換OR (適用於索引列)
通常情況下, 用UNION替換Where子句中的OR將會起到較好的效果. 對索引列使用OR將造成全表掃描. 注意, 以上規則只針對多個索引列有效. 如果有column沒有被索引, 查詢效率可能會因為你沒有選擇OR而降低. 在下面的'例子中, LOC_ID 和REGION上都建有索引.這個在專案中我是有遇到過的，我寫了個臨時表的函式，其他的SQL需要和臨時表連線起來，因為業務邏輯比較複雜，連線的時候速度很慢，後來把OR都改成了UNION ALL
9，避免在索引列上使用IS NULL和IS NOT NULL
10，避免改變索引列的型別
11. 需要當心的Where子句:
某些Select 語句中的Where子句不使用索引. 這裡有一些例子.
在下面的例子裡, (1)‘!=' 將不使用索引. 記住, 索引只能告訴你什麼存在於表中, 而不能告訴你什麼不存在於表中. (2) ‘||'是字元連線函式. 就象其他函式那樣, 停用了索引.
(3) ‘+'是數學函式. 就象其他數學函式那樣, 停用了索引. (4)相同的索引列不能互相比較,這將會啟用全表掃描.
12. 優化GROUP BY:提高GROUP BY 語句的效率, 可以通過將不需要的記錄在GROUP BY 之前過濾掉.
13. 避免使用耗費資源的操作:
帶有DISTINCT,UNION,MINUS,INTERSECT,ORDER BY的SQL語句會啟動SQL引擎
執 行耗費資源的排序(SORT)功能. DISTINCT需要一次排序操作, 而其他的至少需要執行兩次排序. 通常, 帶有UNION, MINUS , INTERSECT的SQL語句都可以用其他方式重寫. 如果你的資料庫的SORT_AREA_SIZE調配得好, 使用UNION , MINUS, INTERSECT也是可以考慮的, 畢竟它們的可讀性很強
SSMS,If you want to see how much cpu time did one query consumed,you can use the following flow:
SET STATISTICS IO ON
set statistics time on
execute your query
set statistics time off
and after this you have to look messages window not results window
