一、基礎規范

使用InnoDB存儲引擎
支持事務、行級鎖、并發性能更好、CPU及內存緩存頁優化使得資源利用率更高

推薦使用utf8mb4字符集
無需轉碼，無亂碼風險, 支持emoji表情以及部分不常見漢字

表、字段必須加注釋
方便他人理解字段意思，在后期維護中非常非常有用，不用去瞎猜這個字段是干嘛的。

不在數據庫做計算
禁止使用存儲過程、視圖、觸發器、Event。
在并發量大的情況下，這些功能很可能將數據庫拖跨，業務邏輯放到服務層具備更好的擴展性，能夠輕易實現“增機器就加性能”

禁止存儲文件
文件存儲在文件系統，數據庫里存URI

控制單表數據量
單表記錄控制在千萬級

二、命名規范

庫名、表名、字段名：小寫，下劃線風格
非唯一索引名idxxxx，唯一索引名uniqxxx

表必須有主鍵，例如自增主鍵
a）主鍵遞增，數據行寫入可以提高插入性能
b）主鍵要選擇較短的數據類型，Innodb引擎普通索引都會保存主鍵的值，較短的數據類型可以有效的減少索引的磁盤空間，提高索引的緩存效率
c）保證實體的完整性，唯一性

不要使用外鍵，如果有外鍵約束，用應用程序控制
外鍵會導致表與表之間耦合，update與delete操作都會涉及相關聯的表，十分影響sql 的性能，甚至會造成死鎖。高并發情況下容易造成數據庫性能下降，大數據高并發業務場景數據庫使用以性能優先

三、字段設計規范

把字段定義為NOT NULL并且提供默認值
a）null的列使索引/索引統計/值比較都更加復雜，對MySQL來說更難優化
b）null 這種類型MySQL內部需要進行特殊處理，增加數據庫處理記錄的復雜性；同等條件下，表中有較多空字段的時候，數據庫的處理性能會降低很多
c）null值需要更多的存儲空間，無論是表還是索引中每行中的null的列都需要額外的空間來標識
d）對null 的處理時候，只能采用is null或is not null，而不能采用=、in、<、<>、!=、not in這些操作符號。如：where name!=’zhangsan’，如果存在name為null值的記錄，查詢結果就不會包含name為null值的記錄

不要使用TEXT、BLOB類型
會浪費更多的磁盤和內存空間，非必要的大量的大字段查詢會淘汰掉熱數據，導致內存命中率急劇降低，影響數據庫性能,如果必須要使用則獨立出來一張表，用主鍵來對應，避免影響其它字段索引效率

不要使用小數存儲貨幣
建議使用整數，小數容易導致錢對不上

必須使用varchar存儲手機號
手機號會去做數學運算么？

為提高效率可以犧牲范式設計，冗余數據
a)不是頻繁修改的字段
b)不是 varchar 超長字段，更不能是 text 字段

四、索引設計規范

禁止在更新十分頻繁、區分度不高的屬性上建立索引
a）更新會變更B+樹，更新頻繁的字段建立索引會大大降低數據庫性能
b）“性別”這種區分度不大的屬性，建立索引是沒有什么意義的

建立組合索引，必須把區分度高的字段放在最左邊
因為使用單字段查詢時會使用組合索引的左邊字段而不使用右邊的字段，如果 where a=? and b=? ， a 列的幾乎接近于唯一值，那么只需要單建 idx_a 索引即可

頁面搜索嚴禁左模糊或者全模糊
索引文件具有 B-Tree 的最左前綴匹配特性，如果左邊的值未確定，那么無法使用此索引, 如果需要請走搜索引擎來解決

五、SQL使用規范

禁止使用SELECT *，只獲取必要的字段，需要顯示說明列屬性
a）消耗cpu，io，內存，帶寬
b）不能有效的利用覆蓋索引
c）使用SELECT *容易在增加或者刪除字段后出現程序BUG, 不具有擴展性

使用INSERT INTO t_xxx VALUES(xxx)，必須顯示指定插入的列屬性
容易在增加或者刪除字段后出現程序BUG

務必請使用“同類型”進行比較，否則可能全表掃面
SELECT name FROM t_user WHERE phone=1888888888 會導致全表掃描.

禁止在WHERE條件的上使用函數或者計算
解讀：SELECT naem FROM tuser WHERE date(createdatatime)='2017-12-29' 會導致全表掃描
推薦的寫法是：SELECT name FROM tuser WHERE createdatatime>= '2017-12-29' and create_datatime < '2017-12-30'

禁止負向查詢，以及%開頭的模糊查詢
a）負向查詢條件：NOT、!=、<>、!<、!>、NOT IN、NOT LIKE等，會導致全表掃描
b）%開頭的模糊查詢，會導致全表掃描

不要大表使用JOIN查詢，禁止大表使用子查詢
會產生臨時表，消耗較多內存與CPU，極大影響數據庫性能

OR改寫為IN()或者UNION
原因很簡單or不會走索引

簡單的事務
事務就像程序中的鎖一樣粒度盡可能要小

不要一次更新大量數據
數據更新會對行或者表加鎖，應該分為多次更新

總結

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

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