MySQL 相關規約（v1.0）

0）前言

a. 基本規約

【強制】表存儲引擎必須使用InnoDB（針對主庫通常是強制要求的）

【強制】表字符集默認使用utf8，必要時候使用utf8mb4（我的踩坑：emoji表情存儲問題）

• 說明：
  1. 通用，無亂碼風險，漢字3字節，英文1字節
  2. utf8mb4是utf8的超集，有存儲4字節例如表情符號時，使用它

 【強制】禁止使用存儲過程，視圖，觸發器，Event

• 說明
  1. 對數據庫性能影響較大，互聯網業務，能讓站點層和服務層乾的事情，不要交到數據庫層
  2. 調試，排錯，遷移都比較困難，擴展性較差

【強制】禁止在數據庫中存儲大文件，例如照片，能夠將大文件存儲在對象存儲系統，數據庫中存儲路徑

【強制】禁止在線上環境作數據庫壓力測試

【強制】測試，開發，線上數據庫環境必須隔離

b. 命名規範

【強制】庫名，表名，列名必須用小寫，採用下劃線分隔

• 說明：abc，Abc，ABC都是給本身埋坑

【推薦】庫名，表名，列名必須見名知義，長度不要超過32字符

• 說明：tmp，wushan誰TM知道這些庫是幹嗎的

【推薦】庫備份必須以bak爲前綴，以日期爲後綴

【推薦】從庫必須以-s爲後綴

【推薦】備庫必須以-ss爲後綴

1）建表規約

【強制】單實例表個數必須控制在2000個之內

【強制】單表分表個數必須控制在1024個之內

【強制】表必須有主鍵，推薦使用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須要更多的存儲空間
  3. NULL只能採用IS NULL或者IS NOT NULL，而在=/!=/in/not in時有大坑

 【強制】使用INT UNSIGNED存儲IPv4，不要用char(15)

 【強制】使用varchar(20)存儲手機號，不要使用整數

• 說明：
  1. 牽扯到國家代號，可能出現+/-/()等字符，例如+86
  2. 手機號不會用來作數學運算
  3. varchar能夠模糊查詢，例如like ‘138%’

 【強制】使用TINYINT來代替ENUM

• 說明：ENUM增長新值要進行DDL操做

【強制】表達是與否概念的字段，必須使用 is_xxx 的方式命名，數據類型是 unsigned tinyint ( 1表示是，0表示否)。

• 說明:任何字段若是爲非負數，必須是 unsigned。
• 正例:表達邏輯刪除的字段名 is_deleted，1 表示刪除，0 表示未刪除。

【強制】表名、字段名必須使用小寫字母或數字，禁止出現數字開頭，禁止兩個下劃線中間只 出現數字。數據庫字段名的修改代價很大，由於沒法進行預發佈，因此字段名稱須要慎重考慮。

• 說明:MySQL 在 Windows 下不區分大小寫，但在 Linux 下默認是區分大小寫。所以，數據庫 名、表名、字段名，都不容許出現任何大寫字母，避免節外生枝。
• 正例:aliyun_admin，rdc_config，level3_name
• 反例:AliyunAdmin，rdcConfig，level_3_name

【強制】表名不使用複數名詞。

• 說明:表名應該僅僅表示表裏面的實體內容，不該該表示實體數量，對應於 DO 類名也是單數 形式，符合表達習慣。

【強制】禁用保留字，如 desc、range、match、delayed 等，請參考 MySQL 官方保留字。

【強制】主鍵索引名爲 pk_字段名;惟一索引名爲 uk_字段名;普通索引名則爲 idx_字段名。

• 說明:pk_ 即 primary key;uk_ 即 unique key;idx_ 即 index 的簡稱。

【推薦】小數類型爲 decimal，禁止使用 float 和 double。

• 說明:float 和 double 在存儲的時候，存在精度損失的問題，極可能在值的比較時，獲得不 正確的結果。若是存儲的數據範圍超過 decimal 的範圍，建議將數據拆成整數和小數分開存儲。

【強制】若是存儲的字符串長度幾乎相等，使用 char 定長字符串類型。

【強制】varchar 是可變長字符串，不預先分配存儲空間，長度不要超過 5000，若是存儲長 度大於此值，定義字段類型爲 text，獨立出來一張表，用主鍵來對應，避免影響其它字段索 引效率。

【強制】表必備三字段:id, gmt_create, gmt_modified。

• 說明:其中id必爲主鍵，類型爲unsigned bigint、單表時自增、步長爲1。gmt_create, gmt_modified 的類型均爲 date_time 類型，前者如今時表示主動建立，後者過去分詞表示被 動更新。

【推薦】表的命名最好是加上「業務名稱_表的做用」。

• 正例:alipay_task / force_project / trade_config

【推薦】庫名與應用名稱儘可能一致。

【推薦】若是修改字段含義或對字段表示的狀態追加時，須要及時更新字段註釋。

【推薦】字段容許適當冗餘，以提升查詢性能，但必須考慮數據一致。冗餘字段應遵循:  1)不是頻繁修改的字段。 2)不是 varchar 超長字段，更不能是 text 字段。

• 正例:商品類目名稱使用頻率高，字段長度短，名稱基本一成不變，可在相關聯的表中冗餘存 儲類目名稱，避免關聯查詢。

【推薦】單錶行數超過 500 萬行或者單表容量超過 2GB，才推薦進行分庫分表。

• 說明:若是預計三年後的數據量根本達不到這個級別，請不要在建立表時就分庫分表。

【參考】合適的字符存儲長度，不但節約數據庫表空間、節約索引存儲，更重要的是提高檢 索速度。

• 正例:以下表，其中無符號值能夠避免誤存負數，且擴大了表示範圍。

對象	年齡區間	類型	字節	表示範圍
人	150 歲以內	unsigned tinyint	1	無符號值:0 到 255
龜	數百歲	unsigned smallint	2	無符號值:0 到 65535
恐龍化石	數千萬年	unsigned int	4	無符號值:0 到約 42.9 億
太陽	約 50 億年	unsigned bigint	8	無符號值:0 到約 10 的 19 次方

2）索引規約

【推薦】惟一索引使用uniq_[字段名]來命名

【推薦】非惟一索引使用idx_[字段名]來命名

【推薦】單張表索引數量建議控制在5個之內

• 說明：
  1. 互聯網高併發業務，太多索引會影響寫性能
  2. 生成執行計劃時，若是索引太多，會下降性能，並可能致使MySQL選擇不到最優索引
  3. 異常複雜的查詢需求，能夠選擇ES等更爲適合的方式存儲

 【推薦】組合索引字段數不建議超過5個

• 說明：若是5個字段還不能極大縮小row範圍，八成是設計有問題

【推薦】不建議在頻繁更新的字段上創建索引

【推薦】非必要不要進行JOIN查詢，若是要進行JOIN查詢，被JOIN的字段必須類型相同，並創建索引

• 說明：踩過由於JOIN字段類型不一致，而致使全表掃描的坑麼？

【推薦】理解組合索引最左前綴原則，避免重複建設索引，若是創建了(a,b,c)，至關於創建了(a), (a,b), (a,b,c)

【強制】業務上具備惟一特性的字段，即便是多個字段的組合，也必須建成惟一索引。

• 說明:不要覺得惟一索引影響了 insert 速度，這個速度損耗能夠忽略，但提升查找速度是明 顯的;另外，即便在應用層作了很是完善的校驗控制，只要沒有惟一索引，根據墨菲定律，必 然有髒數據產生。

【強制】超過三個表禁止 join。須要 join 的字段，數據類型必須絕對一致;多表關聯查詢時， 保證被關聯的字段須要有索引。

• 說明:即便雙表 join 也要注意表索引、SQL 性能。

【強制】在 varchar 字段上創建索引時，必須指定索引長度，不必對全字段創建索引，根據 實際文本區分度決定索引長度便可。

• 說明:索引的長度與區分度是一對矛盾體，通常對字符串類型數據，長度爲 20 的索引，區分度會高達 90%以上，可使用 count(distinct left(列名, 索引長度))/count(*)的區分度來肯定。

【強制】頁面搜索嚴禁左模糊或者全模糊，若是須要請走搜索引擎來解決。

• 說明:索引文件具備 B-Tree 的最左前綴匹配特性，若是左邊的值未肯定，那麼沒法使用此索 引。

【推薦】若是有 order by 的場景，請注意利用索引的有序性。order by 最後的字段是組合 索引的一部分，而且放在索引組合順序的最後，避免出現 file_sort 的狀況，影響查詢性能。

• 正例:where a=? and b=? order by c; 索引:a_b_c
• 反例:索引中有範圍查找，那麼索引有序性沒法利用，如:WHERE a>10 ORDER BY b; 索引 a_b 沒法排序。

【推薦】利用覆蓋索引來進行查詢操做，避免回表。

• 說明:若是一本書須要知道第 11 章是什麼標題，會翻開第 11 章對應的那一頁嗎?目錄瀏覽 一下就好，這個目錄就是起到覆蓋索引的做用。 正例:可以創建索引的種類:主鍵索引、惟一索引、普通索引，而覆蓋索引是一種查詢的一種 效果，用explain的結果，extra列會出現:using index。

【推薦】利用延遲關聯或者子查詢優化超多分頁場景。

• 說明:MySQL 並非跳過 offset 行，而是取 offset+N 行，而後返回放棄前 offset 行，返回 N 行，那當 offset 特別大的時候，效率就很是的低下，要麼控制返回的總頁數，要麼對超過 特定閾值的頁數進行 SQL 改寫。
• 正例:先快速定位須要獲取的 id 段，而後再關聯: SELECT a.* FROM 表 1 a, (select id from 表 1 where 條件 LIMIT 100000,20 ) b where a.id=b.id

【推薦】SQL 性能優化的目標:至少要達到 range 級別，要求是 ref 級別，若是能夠是 consts 最好。

• 說明:
  1. consts 單表中最多隻有一個匹配行(主鍵或者惟一索引)，在優化階段便可讀取到數據。
  2. ref 指的是使用普通的索引(normal index)。
  3. range 對索引進行範圍檢索。
• 反例:explain 表的結果，type=index，索引物理文件全掃描，速度很是慢，這個 index 級 別比較 range 還低，與全表掃描是小巫見大巫。

【推薦】建組合索引的時候，區分度最高的在最左邊。

• 正例:若是 where a=? and b=? ，a 列的幾乎接近於惟一值，那麼只須要單建 idx_a 索引即 可。
• 說明:存在非等號和等號混合判斷條件時，在建索引時，請把等號條件的列前置。如:where a>? and b=? 那麼即便 a 的區分度更高，也必須把 b 放在索引的最前列。

【推薦】防止因字段類型不一樣形成的隱式轉換，致使索引失效。

【參考】建立索引時避免有以下極端誤解:

1. 寧濫勿缺。認爲一個查詢就須要建一個索引。
2. 寧缺勿濫。認爲索引會消耗空間、嚴重拖慢更新和新增速度。
3. 抵制唯一索引。認爲業務的唯一性一概須要在應用層經過「先查後插」方式解決。

3）查詢規約

【強制】禁止使用select *，只獲取必要字段

• 說明：
  1. select *會增長cpu/io/內存/帶寬的消耗
  2. 指定字段能有效利用索引覆蓋
  3. 指定字段查詢，在表結構變動時，能保證對應用程序無影響

【推薦】insert必須指定字段，禁止使用insert into T values()

• 說明：指定字段插入，在表結構變動時，能保證對應用程序無影響

【強制】隱式類型轉換會使索引失效，致使全表掃描

【強制】禁止在where條件列使用函數或者表達式

• 說明：致使不能命中索引，全表掃描

【強制】禁止負向查詢以及%開頭的模糊查詢

• 說明：致使不能命中索引，全表掃描

【強制】禁止大表JOIN和子查詢（非離線大數據庫）

【推薦】同一個字段上的OR必須改寫問IN，IN的值必須少於50個

【推薦】應用程序必須捕獲SQL異常

• 說明：方便定位線上問題

【強制】不要使用 count(列名)或 count(常量)來替代 count(*)，count(*)是 SQL92 定義的 標準統計行數的語法，跟數據庫無關，跟 NULL 和非 NULL 無關。

• 說明:count(*)會統計值爲 NULL 的行，而 count(列名)不會統計此列爲 NULL 值的行。

【強制】count(distinct col) 計算該列除 NULL 以外的不重複行數，注意 count(distinct col1, col2) 若是其中一列全爲NULL，那麼即便另外一列有不一樣的值，也返回爲0。

【強制】當某一列的值全是 NULL 時，count(col)的返回結果爲 0，但 sum(col)的返回結果爲 NULL，所以使用 sum()時需注意 NPE 問題。

• 正例:可使用以下方式來避免sum的NPE問題:SELECT IF(ISNULL(SUM(g)),0,SUM(g)) FROM table;

【強制】使用 ISNULL()來判斷是否爲 NULL 值。

• 說明:NULL 與任何值的直接比較都爲 NULL。
• NULL<>NULL的返回結果是NULL，而不是false。
• NULL=NULL的返回結果是NULL，而不是true。
• NULL<>1的返回結果是NULL，而不是true。

【強制】 在代碼中寫分頁查詢邏輯時，若 count 爲 0 應直接返回，避免執行後面的分頁語句。

【強制】不得使用外鍵與級聯，一切外鍵概念必須在應用層解決。

• 說明:以學生和成績的關係爲例，學生表中的 student_id 是主鍵，那麼成績表中的 student_id 則爲外鍵。若是更新學生表中的 student_id，同時觸發成績表中的 student_id 更新，即爲 級聯更新。外鍵與級聯更新適用於單機低併發，不適合分佈式、高併發集羣;級聯更新是強阻 塞，存在數據庫更新風暴的風險;外鍵影響數據庫的插入速度。

【強制】禁止使用存儲過程，存儲過程難以調試和擴展，更沒有移植性。

【強制】數據訂正時，刪除和修改記錄時，要先 select，避免出現誤刪除，確認無誤才能執 行更新語句。

【推薦】in 操做能避免則避免，若實在避免不了，須要仔細評估 in 後邊的集合元素數量，控制在 1000 個以內。

【參考】若是有全球化須要，全部的字符存儲與表示，均以 utf-8 編碼，注意字符統計函數 的區別。

• 說明:
  • SELECT LENGTH("輕鬆工做"); 返回爲12
  • SELECT CHARACTER_LENGTH("輕鬆工做"); 返回爲4 若是須要存儲表情，那麼選擇 utfmb4 來進行存儲，注意它與 utf-8 編碼的區別。

【參考】TRUNCATE TABLE 比 DELETE 速度快，且使用的系統和事務日誌資源少，但 TRUNCATE 無事務且不觸發 trigger，有可能形成事故，故不建議在開發代碼中使用此語句。

• 說明:TRUNCATE TABLE 在功能上與不帶 WHERE 子句的 DELETE 語句相同。

 

參考材料：

1）https://mp.weixin.qq.com/s/YfCORbcCX1hymXBCrZbAZg

2）https://yq.aliyun.com/articles/73861