常去想想以前的東西，懷舊不是用感傷的，是溫故知新，加油！！！

一、分析一個SQL：

1.先看錶結構，美化一下，一個好看的結構會讓人心曠神怡

2.對複雜的SQL進行分析

（1）儘量將複雜的SQL拆成幾個簡單的查詢

（2）儘量使用表連線，減少使用過 in/not in

（3）儘量減少子查詢的使用或者將其合併出來

（4）儘量將 in/ not in /exists/not exists變為 join 語句，減少/合併子查詢

3.從MySQL 5.6開始，子查詢處理變得相對智慧，利用其進行優化

（1）注意空值變化

（2）適當進左連線

（3）將SQL進行不同方式靈活轉換，測試效能

4.檢視慢查詢日誌，主要看兩個地方

i. Row examined（最終要依據）

ii. Query time

5.SQL對系統可擴充套件性的影響

是否產生了慢查詢，產生全表掃描，時間
中介軟體的影響

二、 分析SQL表連線圖，畫出拓撲圖，找出主外來鍵：

三、 找出返回資料最少的那張表

四、是否有高效索引

1、 高效索引：where條件都在索引上，或者通過索引過濾更多的資料，減少通過索引訪問資料的再次過濾

2、有索引的where條件通過索引訪問表上的資料

3、沒有索引的where條件是通過where過濾資料

五、在表連線順序確定的情況下，確定被連線的表是否存在索引

六、進一步檢視是否覆蓋索引

七、對索引效果不好的情況，是否需要進行表分割槽？

八、是否進行逆正規化化進行？

九、對錶進行水平和垂直拆分

注意：必須有主鍵，儘量保證業務的均勻分配，優先考慮tps

十、注意書寫規範！！！！！！！

1.%開頭的問題！！！

2.字元列上面沒有加引號！！！

where條件不能有計算與函式處理 ！！

十一、索引失效原因

1.沒有查詢條件，或者查詢條件沒有建立索引

2.查詢條件上沒有使用引導列，多列索引沒有正確被使用（where條件沒有寫前導列）

3.查詢的數量是大表的大部分

如果有主鍵索引，都要走主鍵索引
對於二級索引，如果訪問量大，會全表掃描

4.索引本身失效

5.查詢條件使用函式或者計算

6.對於小表進行查詢

7.忽略索引的問題

8.隱式轉換導致索引失效！！！！！

數字列不害怕隱式轉換
字元列害怕隱式轉換

9.<>不等於號不一定不走索引

10.%開頭的情況，索引一定失效

11.not in /not exists 多數情況下不走索引

12.當變數是times型別，表字段是data的時候，或相反情況下，索引失效。而且如果資料填充進去也不對

13.注意非空的情況，B-tree索引處理的不是很好