面試中常見的SQL優化問題

一、表的設計
0、必須使用默認的InnoDB存儲引擎--支持事務、行級鎖、併發性能好、CPU及內存緩存頁優化使得資源利用率高
1、表和字段使用中文註釋--便於後人理解
2、使用默認utf8mb4字符集--標準、萬國碼、無亂碼風險、無需轉碼
3、禁止使用觸發器、視圖、存儲過程和event
4、禁止使用外鍵--外鍵導致表之間的耦合，update和delete操作都會涉及相關表，影響性能
--架構方向：對數據庫性能影響較大的特性少用；應將計算集中在服務層，解放數據庫CPU；數據庫擅長索引和存儲，勿讓數據庫揹負重負
5、禁止存大文件或者照片--在數據庫裏存儲URI
字段：
6、必須把字段定義爲NOT NULL並設置默認值--null值需要更多的存儲空間；
字段中有null值的話,name != 'san' 查詢結果中不包含name is null的記錄
7、禁止使用TEXT/BOLB字段類型--浪費磁盤和內存空間，非必要的大量的大字段查詢導致內存命中率降低，影響數據庫性能
索引：
8、單表索引控制在5個以內
9、單索引不超過5個字段--超過5個以及起不到有效過濾數據的效果
10、建立組合索引，必須把區分度高的字段放在前邊--更加有效的過濾數據
11、數據區分度不大的字段不易使用索引--例如：性別只有男，女，訂單狀態，每次過濾數據很少




二、SQL查詢規範：
1、禁止使用select *，只獲取需要的字段--查詢很多無用字段，增加CPU/IO/NET消耗；不能有效的利用覆蓋索引；增刪字段易出bug
2、禁止使用屬性的隱式轉換select * from customer where phone=123123--會導致全表掃描，不能命中索引
3、禁止在where條件上使用函數和計算
4、禁止負向查詢（NOT != <> !< !> MOT IN NOT LIKE）和%開頭的like（前導模糊查詢）--會導致全表掃描
5、禁止大表使用JOIN查詢和子查詢--會產生臨時表，消耗較多CPU和內存，影響數據庫性能
6、在屬性上進行計算不能命中索引--如 select * from order where YEAR(date) <= '2017'不能命中索引導致全表掃描
7、複合索引最左前綴--例如user 表建立了（userid,phone）的聯合索引
有如下幾種寫法：
（1）select * from user where userid = ? and phone = ?
(2)select * from user where phone=? and userid= ?
(3)select * from user where phone = ?
(4)select * from user where userid = ?
其中（1）（2）（4）可以命中索引，（3）會導致全表掃描


8、明知道只有一條記錄返回，建議加上limit 1








參考文章：http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=504476631&idx=1&sn=e36a083ef4bfcb33cfbf945cb8a37b79&chksm=3d2d060b0a5a8f1db22f21d24cd92577dbb3abcee08b1dd771e7b27ed1b0997af304561c0ab5&mpshare=1&scene=23&srcid=0920u9JMQ216HlTCCxyiK0j6#rd
http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=504476256&idx=1&sn=517cda6790e181d0b96e1599f75ad055&chksm=3d2d07bc0a5a8eaa8a7e6e8d639fabc96edeb97aa28a088fc1cb8973d52e4580660f654af826&mpshare=1&scene=23&srcid=0920F8OavtK3XvhwtBpUNJkW#rd