總結幾點sql 性能優化
一.表設計階段：
1.主鍵的使用
a.業務日誌表、安全審計表采用自增長；
b.自定義編號用於業務流程類表，根據一定的編號規則；
c.int型主鍵 用於基礎數據表；
2.邏輯刪除字段的設計
a.tinyint類型，1或0；
b.聯合主鍵(如ID+starDate)，另加starDate，endDate日期類型字段過濾數據；
3.盡量避免null值存在，盡可能使用默認值進行填充；
4.盡量使用varchar/nvarchar 代替 char/nchar；
二.查詢語句註意事項
百萬級數據庫查詢優化的出發點主要基於盡量避免全表掃描；
1.眾所周知的像在WHERE ORDER 語句上的字段添加索引；（索引使用上的考慮和權衡，後續還會有總結的博文）
2.查詢列用列名代替*，COUNT(1)取代COUNT(*)；
3.盡量避免WHERE 子句上和NULL的邏輯判斷，如：WHERE NAME IS NULL;
4.盡量避免WHERE 子句上使用表達式，如：select goods fromwarehouse where num/2=500 改為 select goods from warehouse where num=500/2；
5.盡量避免WHERE 子句上使用內置函數或標量函數；
6.盡量避免WHERE子句上<>和！=的出現；
7.盡量避免WHERE子句上OR 連接非索引列；
8.盡量避免like的使用；
9.不要在 where 子句中的“=”左邊進行函數、算術運算或其他表達式運算；
10.對於多張大數據量的表JOIN，要先分頁再JOIN，否則邏輯讀會很高，性能很差。
11.用 EXISTS代替 IN 是一個好的選擇,如：select [score] from score where name in (select [name] from student)改成 select [score] from score where exists(select 1 from student );
12.查詢語句通過拼接的Where子句帶有參數的也會導致全表掃描。
因為SQL只有在運行時才會解析局部變量，但優化程序不能將訪問計劃的選擇推遲到運行時；它必須在編譯時進行選擇。然而，如果在編譯時建立訪問計劃，變量的值還是未知的，因而無法作為索引選擇的輸入項。
解決的方法是可以改為強制查詢使用索引：select [address] from student where [email protected] 改為 select [address] from student with(index(‘indexname‘))where [email protected];
13.索引並不是越多越好，一張表上最多不超過6個，後續我會針對索引的使用進行詳細的總結；
14.能用數值的字段盡量不用字符；
以上內容為本人近期項目中總結以及參考網上賢人誌士的文章進行梳理總結，以便增強個人在sql使用上的技巧性；
不足之處還請糾正補充！
引用連接：http://database.51cto.com/art/201407/445934.htm
總結幾點sql 性能優化