一、建庫建表優化
1、核心規範（推薦）
- 表字符集選擇UTF8 （“表情”欄位單獨設定為其他字符集）
- 儲存引擎使用INNODB
- 不在庫中儲存圖片、檔案等
- 使用可變長字串（varchar）
- 每張表資料量控制在5000W以下
2、欄位命名規範（建議）
- 庫名、表名、欄位名、索引名使用小寫字母，以下劃線分割
- 非唯一索引按照“idx_欄位名[_欄位名]”進行命名
- 唯一索引按照“uniq_欄位名[_欄位名]”進行命名（不要直接採用欄位名稱定義索引名稱。防止刪除索引時，誤刪除欄位）
3、欄位屬性規則（建議）
- 所有欄位均定義為 NOT NULL（null會降低索引效果;索引會產生額外的空間）
- ·使用unsigned儲存非負整數
- ·使用timestamp儲存時間（可利用該型別的預設值，進行查詢優化）
4、欄位型別規則（推薦）
- 使用tinyint來代替enum型別
- 儘可能不用text、blob型別
- 將字元轉化為數字
- 儲存 “abcd” 時 varchar(5) 比 varchar(10) 更優
5、索引規則（推薦）
- 選擇自增列作為主鍵
- 單表索引數不超過5個、單個索引欄位數不超過5個
- 字串可使用字首索引，字首長度控制在5-8個字元
- 不在低基數列上建立索引，如：性別、是否刪除、是否釋出
- 不使用select * 優化成 select id,name,age……..
- 不在索引列進行數學運算、函式
6、SQL規範
- 避免隱式轉換
- 避免使用儲存過程、觸發器、函式
- 避免進行數學運算
- 儘可能拆分大SQL
二、建立高效索引
目的：加速查詢、加速排序、覆蓋索引（只需要在索引中完成查詢，不需要回到表中）
1、主鍵：和資料儲存在一起。
- 通常選擇自增列作為主鍵
- 優點：
- a 順序插入，不會出現資料頁內資料移動的情況發生（插入更快）
- b 資料儲存更緊湊（查詢更快）
- 缺點：
- 多出4至8位元組無意義的資料
2、二級索引：和資料分開儲存
- 二級索引中是按照索引列+主鍵的對應關係進行儲存的，每多一個索引就會多一個這樣的對應關係。所以索引的個數越多，佔用空間越大，在插入、刪除的時候會越慢。
3、什麼樣的欄位適合加索引？
- 首先，要滿足主要功能的查詢條件。
- 其次，要看該欄位的唯一值多少。
- 唯一值： select count(distinct uid)/count(1) from table; 值越大，索引效果越好。
type ：建議優化的型別
-
-
- system 表只有一行
- const 用到的是主鍵或唯一索引 eq_ref 多表查詢時，匹配到了1行，並且利用的是主鍵或唯一索引
- ref 匹配到了多行，通常是利用的普通索引（如果是聯合唯一索引，只用到了其中1個也是這個型別）
- ref_or_null 與ref類似，條件中用到了 null 的搜尋
-
-
-
- all 沒有用到索引
- 出現上面所列之外的型別時，如range、index等說明用到的索引效能很差
-
rows：
-
-
- 查詢影響的行數，值越小越優。
-
extra：
-
-
- 查詢的詳細資訊，型別包括：
- using where、using index、using filesort等都是正常查詢過程
- using temporary 出現時，說明需要對sql或索引進行優化
-
二、優化SQL
- 需要多表查詢時，內（外）連線查詢不一定是最佳的方案，適當的採用子查詢，會是更好的選擇。
- 把 select * 換成部分欄位，可少許降低查詢時間
- 垃圾索引只會影響插入、刪除效率，對查詢速度影響較小。
- 欄位唯一性太低，索引效率不高。
- 欄位唯一性非常高，索引的效能會很優秀。
- 時間範圍很大時，用不到索引。儘可能讓時間範圍有開口和閉口，區間也不易過大，根據資料量及最早時間來決定。