一、建庫建表優化

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 * 換成部分字段，可少許降低查詢時間
• 垃圾索引只會影響插入、刪除效率，對查詢速度影響較小。
• 字段唯一性太低，索引效率不高。
• 字段唯一性非常高，索引的性能會很優秀。
• 時間范圍很大時，用不到索引。盡可能讓時間范圍有開口和閉口，區間也不易過大，根據數據量及最早時間來決定。

?

轉載于:https://www.cnblogs.com/sunchong/p/8521882.html

總結

以上是生活随笔為你收集整理的MySQL 规范及优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。