MySQL 規範及優化
阿新 • • 發佈:2018-03-08
sys nod 直接 gpo 決定 行數 其中 blog 文件
一、建庫建表優化
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 * 換成部分字段,可少許降低查詢時間
- 垃圾索引只會影響插入、刪除效率,對查詢速度影響較小。
- 字段唯一性太低,索引效率不高。
- 字段唯一性非常高,索引的性能會很優秀。
- 時間範圍很大時,用不到索引。盡可能讓時間範圍有開口和閉口,區間也不易過大,根據數據量及最早時間來決定。
MySQL 規範及優化