一、基礎規範
-
表存儲引擎必須使用InnoDB
解讀:支持事務、行級鎖、併發性能更好、CPU及內存緩存頁優化使得資源利用率更高
- 表字符集默認使用utf8,必要時候使用utf8mb4
解讀:
(1)通用,無亂碼風險,漢字3字節,英文1字節
(2)utf8mb4是utf8的超集,有存儲4字節例如表情符號時,使用它
- 禁止使用存儲過程,視圖,觸發器,Event
解讀:
(1)對數據庫性能影響較大,互聯網業務,能讓站點層和服務層乾的事情,不要交到數據庫層
(2)調試,排錯,遷移都比較困難,擴展性較差
- 禁止在數據庫中存儲大文件,例如照片,可以將大文件存儲在對象存儲系統,數據庫中存儲路徑
解讀:爲何要讓數據庫做它不擅長的事情?大文件和照片存儲在文件系統,數據庫裏存URI多好
- 禁止在線上環境做數據庫壓力測試
- 測試,開發,線上數據庫環境必須隔離
二、命名規範
- 庫名,表名必須用小寫,採用下劃線分隔(注:正常情況在MySQL中是使用下劃線作爲單詞分隔,但是由於歷史表規範的問題,爲了風格一致,表名禁止使用下劃線)
解讀: 表名 t******
- 列名單詞首字母大寫(注:正常情況在MySQL中是使用全小寫,下劃線進行單詞分隔,但是由於歷史表規範的問題,爲了風格一致,禁止使用下劃線)
- 庫名,表名,列名必須見名知義,長度不要超過32字符
解讀:tmp,wushan誰知道這些庫是幹嘛的
- 數據表、數據字段必須加入中文註釋
解讀:N年後誰知道這個r1,r2,r3字段是幹嘛的
- 庫備份必須以bak爲前綴,以日期爲後綴
三、表設計規範
- 單實例表個數必須控制在500個以內
- 單表分表個數必須控制在1024個以內
- 單表列數目必須小於50
- 表必須有主鍵,推薦使用UNSIGNED整數爲主鍵
潛在坑:刪除無主鍵的表,如果是row模式的主從架構,從庫會掛住
- 禁止使用外鍵,如果要保證完整性,應由應用程式實現
解讀:外鍵使得表之間相互耦合,影響update/delete等SQL性能,有可能造成死鎖,高併發情況下容易成爲數據庫瓶頸
- 建議將大字段,訪問頻度低的字段拆分到單獨的表中存儲,分離冷熱數據
解讀:垂直拆分
四、列設計規範
- 根據業務區分使用tinyint/int/bigint,分別會佔用1/4/8字節
- 根據業務區分使用char/varchar
解讀:
(1)字段長度固定,或者長度近似的業務場景,適合使用char,能夠減少碎片,查詢性能高
(2)字段長度相差較大,或者更新較少的業務場景,適合使用varchar,能夠減少空間
- 根據業務區分使用datetime/timestamp
解讀:前者佔用5個字節,後者佔用4個字節,存儲年使用YEAR,存儲日期使用DATE,存儲時間使用datetime
- 必須把字段定義爲NOT NULL並設默認值
解讀:
(1)NULL的列使用索引,索引統計,值都更加複雜,MySQL更難優化
(2)null 這種類型MySQL內部需要進行特殊處理,增加數據庫處理記錄的複雜性;同等條件下,表中有較多空字段的時候,數據庫的處理性能會降低很多
(3)null值需要更多的存儲空,無論是表還是索引中每行中的null的列都需要額外的空間來標識
(4)NULL只能採用IS NULL或者IS NOT NULL,而在=/!=/in/not in時有大坑
- 禁止使用TEXT、BLOB類型
解讀:會浪費更多的磁盤和內存空間,非必要的大量的大字段查詢會淘汰掉熱數據,導致內存命中率急劇降低,影響數據庫性能
- 使用varchar(20)存儲手機號,不要使用整數
解讀:
(1)牽扯到國家代號,可能出現+/-/()等字符,例如+86
(2)手機號不會用來做數學運算
(3)varchar可以模糊查詢,例如like ‘138%’
- 使用TINYINT來代替ENUM
解讀:ENUM增加新值要進行DDL操作
五、索引規範
- 唯一索引使用uniq_[字段名]來命名
- 非唯一索引使用idx_[字段名]來命名
- 單張表索引數量建議控制在5個以內
解讀:
(1)互聯網高併發業務,太多索引會影響寫性能
(2)生成執行計劃時,如果索引太多,會降低性能,並可能導致MySQL選擇不到最優索引
(3)異常複雜的查詢需求,可以選擇ES等更爲適合的方式存儲
- 組合索引字段數不建議超過5個
解讀:如果5個字段還不能極大縮小row範圍,八成是設計有問題
- 不建議在頻繁更新的字段上建立索引
- 禁止在區分度不高的字段上建立索引
解讀:“性別”這種區分度不大的字段,建立索引是沒有什麼意義的,不能有效過濾數據,性能與全表掃描類似
- 非必要不要進行JOIN查詢,如果要進行JOIN查詢,被JOIN的字段必須類型相同,並建立索引
解讀:踩過因爲JOIN字段類型不一致,而導致全表掃描的坑麼?
- 建立組合索引,必須把區分度高的字段放在前面
解讀:能夠更加有效的過濾數據
- 理解組合索引最左匹配原則,避免重複建設索引,如果建立了(a,b,c),相當於建立了(a), (a,b), (a,b,c)三個索引
- 注:瞭解組合索引最左匹配原則,請看<<深入淺析Mysql聯合索引原理 之 最左匹配原則>>
六、SQL規範
- 禁止使用select *,只獲取必要字段
解讀:
(1)select *會增加cpu/io/內存/帶寬的消耗
(2)指定字段能有效利用索引覆蓋
(3)指定字段查詢,在表結構變更時,能保證對應用程序無影響
- insert必須指定字段,禁止使用insert into T values()
解讀:指定字段插入,在表結構變更時,能保證對應用程序無影響
- 隱式類型轉換會使索引失效,導致全表掃描
解讀:SELECT uid FROM tuser WHERE phone=13812345678 會導致全表掃描,而不能命中phone索引;int數據類型優先級高於varchar, 該查詢會把phone轉換爲int,因此需要把表中所有數據改成int,所以必須全表掃描
- 禁止在where條件列使用函數或者表達式
解讀:導致不能命中索引,全表掃描
SELECT uid FROM tuser WHERE from_unixtime(day)>='2017-02-15' 會導致全表掃描
正確的寫法是:SELECT uid FROM tuser WHERE day>= unix_timestamp('2017-02-15 00:00:00')
- 禁止負向查詢以及%開頭的模糊查詢
解讀:導致不能命中索引,全表掃描
- 禁止大表JOIN和子查詢
解讀:數據量可能超過50萬的表,禁止此操作,通過簡單語句進行數據拼接,或者通過異構表實現需求
- 同一個字段上的OR必須改寫問IN,IN的值必須少於50個
- 應用程序必須捕獲SQL異常
解讀:方便定位線上問題
說明:本規範適用於併發量大,數據量大的典型互聯網業務
博主其他關於MySql文章,對你有用請幫忙點個贊