1.強制：業務上具有唯一特性的字段，即使是多個字段的組合，也必須建成唯一索引。
說明： 不要以爲唯一索引影響了 insert 速度，這個速度損耗可以忽略，但會明顯提高查找速度；另外，即使在應用層做了非常完善的校驗控制，只要沒有唯一索引，根據墨菲定律，必然有髒數據產生。 |
2.強制：超過三個表禁止 join 。需要 join 的字段，數據類型必須絕對一致；當多表關聯查詢是，保證被關聯的字段需要有索引。
說明： 即使雙表 join 也要注意索引、SQL 性能。 |
說明： 索引的長度與區分度是一對矛盾體，一般對字符串類型數據，長度爲 的 索引 ，區分度會 高達 90% 以上，可以使用 count(distinct left(列名，索引長度)) / count(*) 的區分度來確定。 |
4.強制：頁面搜索嚴禁左模糊或者全模糊，如果需要請通過搜索引擎來解決。
說明： 索引文件具有 B-Tree 的最左前綴匹配特性，如果左邊的值未確定，那麼無法使用此索引。 |
5.推薦：如果有 order by 的場景，請注意利用索引的有序性。order by 最後的字段是組合索引的一部分，並且凡在索引組合順序的最後，避免出現 file_sort 的情況，影響查詢性能。
正例： where a = ? and b = ? order by c ; 索引 ：a_b_c。 反例： 索引中有範圍查找，那麼索引有序性無法利用，如 where a > 10 order by b ; 索引 a_b 無法排序。 |
說明： 如果想知道一本書第 11 章是什麼標題，我們有必要翻開第 11 章對應的那一頁嗎？只瀏覽一下目錄即可，這個目錄就起到了覆蓋索引的作用。 正例： 能過簡歷索引的種類分爲主鍵索引、唯一索引、普通索引三種，而覆蓋索引只是查詢的一種效果，用 explain 的記過， extra 列會出現： using index 。 |
7.推薦：利用延遲關聯或者子查詢優化超多分頁場景。
說明： MySQL 並不是跳過 offset 行，而是去 offset+N 行，然後放棄前 offset 行，返回 N 行，當 offset 特別大的時候，效率會非常的低下，要麼控制返回的總頁數，要麼對超過特定閾值的頁數進行 SQL 改寫。 正例： 先快速定位需要獲取的 id 段，然後再關聯： SELECT a.* from 表1 a, (select id from 表1 where 條件 LIMIT 100000, 20) b where a.id = b.id |
8.推薦：SQL 性能優化的目標：至少是 range 級別，要求是 ref 級別，最好是 consts 。
說明：
反例： explain 表的結果， type = index , 索引物理文件全掃描，速度非常慢，這個 index 級別比 range 還低，與全表掃描相比是小巫見大巫。 |
9.推薦：建組合索引的時候，區分度最高的在最左邊。
正例： 如果 where a = ? and b = ? , a 列幾乎接近於胃一直，那麼只需要單間 idx_a 索引即可。 說明： 如存在非等號和等號混合判斷條件，在建索引的時，請把等號條件的列前置。如 where a > ? and b = ? , 那麼即使 a 的區分度更高，也必須把 b 放在索引的最前列。 |
10.推薦：應防止因字段類型不同造成的飲食轉換，導致索引失效。
11.參考：創建索引時避免有如下極端誤解：
- 寧濫勿缺。認爲一個查詢就需要建一個索引。
- 寧缺勿濫。認爲索引會消耗空間、眼中拖慢更新和新增速度。
- 抵制唯一索引。認爲業務的唯一性一律需要在應用層通過“先查後插”的方式解決。