分享一份大佬的MySQL資料庫設計規範，值得收藏

阿新 • • 發佈：2020-11-24

MySQL資料庫與 Oracle、 SQL Server 等資料庫相比，有其核心上的優勢與劣勢。我們在使用MySQL資料庫的時候需要遵循一定規範，揚長避短。無意中從github上看到一個大佬的MySQL資料庫設計規範，順便在這裡分享一下。

寫的都很實用，建議收藏閱讀。

一、資料庫設計

以下所有規範會按照【高危】、【強制】、【建議】三個級別進行標註，遵守優先順序從高到低。對於不滿足【高危】和【強制】兩個級別的設計，DBA會強制打回要求修改。

1. 庫名

【強制】庫的名稱必須控制在32個字元以內，相關模組的表名與表名之間儘量提現join的關係，如user表和user_login表。
【強制】庫的名稱格式：業務系統名稱_子系統名，同一模組使用的表名儘量使用統一字首。

【強制】一般分庫名稱命名格式是庫通配名_編號，編號從0開始遞增，比如wenda_001以時間進行分庫的名稱格式是“庫通配名_時間”
【強制】建立資料庫時必須顯式指定字符集，並且字符集只能是utf8或者utf8mb4。建立資料庫SQL舉例：create database db1 default character set utf8;。

2. 表結構

【強制】表和列的名稱必須控制在32個字元以內，表名只能使用字母、數字和下劃線，一律小寫。
【強制】表名要求模組名強相關，如師資系統採用”sz”作為字首，渠道系統採用”qd”作為字首等。
【強制】建立表時必須顯式指定字符集為utf8或utf8mb4。
【強制】建立表時必須顯式指定表儲存引擎型別，如無特殊需求，一律為InnoDB。當需要使用除InnoDB/MyISAM/Memory以外的儲存引擎時，必須通過DBA稽核才能在生產環境中使用。因為Innodb表支援事務、行鎖、宕機恢復、MVCC等關係型資料庫重要特性，為業界使用最多的MySQL儲存引擎。而這是其他大多數儲存引擎不具備的，因此首推InnoDB。

【強制】建表必須有comment
【建議】建表時關於主鍵：(1)強制要求主鍵為id，型別為int或bigint，且為auto_increment(2)標識表裡每一行主體的欄位不要設為主鍵，建議設為其他欄位如user_id，order_id等，並建立unique key索引(可參考cdb.teacher表設計)。因為如果設為主鍵且主鍵值為隨機插入，則會導致innodb內部page分裂和大量隨機I/O，效能下降。
【建議】核心表(如使用者表，金錢相關的表)必須有行資料的建立時間欄位create_time和最後更新時間欄位update_time，便於查問題。
【建議】表中所有欄位必須都是NOT NULL屬性，業務可以根據需要定義DEFAULT值。因為使用NULL值會存在每一行都會佔用額外儲存空間、資料遷移容易出錯、聚合函式計算結果偏差等問題。

【建議】建議對錶裡的blob、text等大欄位，垂直拆分到其他表裡，僅在需要讀這些物件的時候才去select。
【建議】反正規化設計：把經常需要join查詢的欄位，在其他表裡冗餘一份。如user_name屬性在user_account，user_login_log等表裡冗餘一份，減少join查詢。
【強制】中間表用於保留中間結果集，名稱必須以tmp_開頭。備份表用於備份或抓取源錶快照，名稱必須以bak_開頭。中間表和備份表定期清理。
【強制】對於超過100W行的大表進行alter table，必須經過DBA稽核，並在業務低峰期執行。因為alter table會產生表鎖，期間阻塞對於該表的所有寫入，對於業務可能會產生極大影響。

3. 列資料型別優化

【建議】表中的自增列(auto_increment屬性)，推薦使用bigint型別。因為無符號int儲存範圍為-2147483648~2147483647(大約21億左右)，溢位後會導致報錯。
【建議】業務中選擇性很少的狀態status、型別type等欄位推薦使用tinytint或者smallint型別節省儲存空間。
【建議】業務中IP地址欄位推薦使用int型別，不推薦用char(15)。因為int只佔4位元組，可以用如下函式相互轉換，而char(15)佔用至少15位元組。一旦表資料行數到了1億，那麼要多用1.1G儲存空間。 SQL：select inet_aton('192.168.2.12'); select inet_ntoa(3232236044); php: ip2long(‘192.168.2.12’); long2ip(3530427185);
【建議】不推薦使用enum，set。因為它們浪費空間，且列舉值寫死了，變更不方便。推薦使用tinyint或smallint。
【建議】不推薦使用blob，text等型別。它們都比較浪費硬碟和記憶體空間。在載入表資料時，會讀取大欄位到記憶體裡從而浪費記憶體空間，影響系統性能。建議和PM、RD溝通，是否真的需要這麼大欄位。Innodb中當一行記錄超過8098位元組時，會將該記錄中選取最長的一個欄位將其768位元組放在原始page裡，該欄位餘下內容放在overflow-page裡。不幸的是在compact行格式下，原始page和overflow-page都會載入。
【建議】儲存金錢的欄位，建議用int，程式端乘以100和除以100進行存取。因為int佔用4位元組，而double佔用8位元組，空間浪費。
【建議】文字資料儘量用varchar儲存。因為varchar是變長儲存，比char更省空間。MySQL server層規定一行所有文字最多存65535位元組，因此在utf8字符集下最多存21844個字元，超過會自動轉換為mediumtext欄位。而text在utf8字符集下最多存21844個字元，mediumtext最多存2^24/3個字元，longtext最多存2^32個字元。一般建議用varchar型別，字元數不要超過2700。
【建議】時間型別儘量選取timestamp。因為datetime佔用8位元組，timestamp僅佔用4位元組，但是範圍為1970-01-01 00:00:01到2038-01-01 00:00:00。更為高階的方法，選用int來儲存時間，使用SQL函式unix_timestamp()和from_unixtime()來進行轉換。

詳細儲存大小參加下圖：

4. 索引設計

【強制】InnoDB表必須主鍵為id int/bigint auto_increment,且主鍵值禁止被更新。
【建議】主鍵的名稱以“pk_”開頭，唯一鍵以“uk_”或“uq_”開頭，普通索引以“idx_”開頭，一律使用小寫格式，以表名/欄位的名稱或縮寫作為字尾。
【強制】InnoDB和MyISAM儲存引擎表，索引型別必須為BTREE;MEMORY表可以根據需要選擇HASH或者BTREE型別索引。
【強制】單個索引中每個索引記錄的長度不能超過64KB。
【建議】單個表上的索引個數不能超過7個。
【建議】在建立索引時，多考慮建立聯合索引，並把區分度最高的欄位放在最前面。如列userid的區分度可由select count(distinct userid)計算出來。
【建議】在多表join的SQL裡，保證被驅動表的連線列上有索引，這樣join執行效率最高。
【建議】建表或加索引時，保證表裡互相不存在冗餘索引。對於MySQL來說，如果表裡已經存在key(a,b)，則key(a)為冗餘索引，需要刪除。

5. 分庫分表、分割槽表

【強制】分割槽表的分割槽欄位(partition-key)必須有索引，或者是組合索引的首列。
【強制】單個分割槽表中的分割槽(包括子分割槽)個數不能超過1024。
【強制】上線前RD或者DBA必須指定分割槽表的建立、清理策略。
【強制】訪問分割槽表的SQL必須包含分割槽鍵。
【建議】單個分割槽檔案不超過2G，總大小不超過50G。建議總分割槽數不超過20個。
【強制】對於分割槽表執行alter table操作，必須在業務低峰期執行。
【強制】採用分庫策略的，庫的數量不能超過1024
【強制】採用分表策略的，表的數量不能超過4096
【建議】單個分表不超過500W行，ibd檔案大小不超過2G，這樣才能讓資料分散式變得效能更佳。
【建議】水平分表儘量用取模方式，日誌、報表類資料建議採用日期進行分表。

6. 字符集

【強制】資料庫本身庫、表、列所有字符集必須保持一致，為utf8或utf8mb4。
【強制】前端程式字符集或者環境變數中的字符集，與資料庫、表的字符集必須一致，統一為utf8。

https://www.renrenfan.com.cn

二、SQL編寫規範

1. DML語句

【強制】SELECT語句必須指定具體欄位名稱，禁止寫成*。因為select *會將不該讀的資料也從MySQL裡讀出來，造成網絡卡壓力。且表字段一旦更新，但model層沒有來得及更新的話，系統會報錯。
【強制】insert語句指定具體欄位名稱，不要寫成insert into t1 values(…)，道理同上。
【建議】insert into…values(XX),(XX),(XX)…。這裡XX的值不要超過5000個。值過多雖然上線很很快，但會引起主從同步延遲。
【建議】SELECT語句不要使用UNION，推薦使用UNION ALL，並且UNION子句個數限制在5個以內。因為union all不需要去重，節省資料庫資源，提高效能。
【建議】in值列表限制在500以內。例如select… where userid in(….500個以內…)，這麼做是為了減少底層掃描，減輕資料庫壓力從而加速查詢。
【建議】事務裡批量更新資料需要控制數量，進行必要的sleep，做到少量多次。
【強制】事務涉及的表必須全部是innodb表。否則一旦失敗不會全部回滾，且易造成主從庫同步終端。
【強制】寫入和事務發往主庫，只讀SQL發往從庫。
【強制】除靜態表或小表(100行以內)，DML語句必須有where條件，且使用索引查詢。
【強制】生產環境禁止使用hint，如sql_no_cache，force index，ignore key，straight join等。因為hint是用來強制SQL按照某個執行計劃來執行，但隨著資料量變化我們無法保證自己當初的預判是正確的，因此我們要相信MySQL優化器!
【強制】where條件裡等號左右欄位型別必須一致，否則無法利用索引。
【建議】SELECT|UPDATE|DELETE|REPLACE要有WHERE子句，且WHERE子句的條件必需使用索引查詢。
【強制】生產資料庫中強烈不推薦大表上發生全表掃描，但對於100行以下的靜態表可以全表掃描。查詢資料量不要超過錶行數的25%，否則不會利用索引。
【強制】WHERE 子句中禁止只使用全模糊的LIKE條件進行查詢，必須有其他等值或範圍查詢條件，否則無法利用索引。
【建議】索引列不要使用函式或表示式，否則無法利用索引。如where length(name)='Admin'或where user_id+2=10023。
【建議】減少使用or語句，可將or語句優化為union，然後在各個where條件上建立索引。如where a=1 or b=2優化為where a=1… union …where b=2, key(a),key(b)。
【建議】分頁查詢，當limit起點較高時，可先用過濾條件進行過濾。如select a,b,c from t1 limit 10000,20;優化為:select a,b,c from t1 where id>10000 limit 20;。

2. 多表連線

【強制】禁止跨db的join語句。因為這樣可以減少模組間耦合，為資料庫拆分奠定堅實基礎。
【強制】禁止在業務的更新類SQL語句中使用join，比如update t1 join t2…。
【建議】不建議使用子查詢，建議將子查詢SQL拆開結合程式多次查詢，或使用join來代替子查詢。
【建議】線上環境，多表join不要超過3個表。
【建議】多表連線查詢推薦使用別名，且SELECT列表中要用別名引用欄位，資料庫.表格式，如select a from db1.table1 alias1 where …。
【建議】在多表join中，儘量選取結果集較小的表作為驅動表，來join其他表。

3. 事務

【建議】事務中INSERT|UPDATE|DELETE|REPLACE語句操作的行數控制在2000以內，以及WHERE子句中IN列表的傳參個數控制在500以內。
【建議】批量操作資料時，需要控制事務處理間隔時間，進行必要的sleep，一般建議值5-10秒。
【建議】對於有auto_increment屬性欄位的表的插入操作，併發需要控制在200以內。
【強制】程式設計必須考慮“資料庫事務隔離級別”帶來的影響，包括髒讀、不可重複讀和幻讀。線上建議事務隔離級別為repeatable-read。
【建議】事務裡包含SQL不超過5個(支付業務除外)。因為過長的事務會導致鎖資料較久，MySQL內部快取、連線消耗過多等雪崩問題。
【建議】事務裡更新語句儘量基於主鍵或unique key，如update … where id=XX; 否則會產生間隙鎖，內部擴大鎖定範圍，導致系統性能下降，產生死鎖。
【建議】儘量把一些典型外部呼叫移出事務，如呼叫webservice，訪問檔案儲存等，從而避免事務過長。
【建議】對於MySQL主從延遲嚴格敏感的select語句，請開啟事務強制訪問主庫。

4. 排序和分組

【建議】減少使用order by，和業務溝通能不排序就不排序，或將排序放到程式端去做。order by、group by、distinct這些語句較為耗費CPU，資料庫的CPU資源是極其寶貴的。
【建議】order by、group by、distinct這些SQL儘量利用索引直接檢索出排序好的資料。如where a=1 order by可以利用key(a,b)。
【建議】包含了order by、group by、distinct這些查詢的語句，where條件過濾出來的結果集請保持在1000行以內，否則SQL會很慢。

5. 線上禁止使用的SQL語句

【高危】禁用update|delete t1 … where a=XX limit XX; 這種帶limit的更新語句。因為會導致主從不一致，導致資料錯亂。建議加上order by PK。
【高危】禁止使用關聯子查詢，如update t1 set … where name in(select name from user where…);效率極其低下。
【強制】禁用procedure、function、trigger、views、event、外來鍵約束。因為他們消耗資料庫資源，降低資料庫例項可擴充套件性。推薦都在程式端實現。
【強制】禁用insert into …on duplicate key update…在高併發環境下，會造成主從不一致。
【強制】禁止聯表更新語句，如update t1,t2 where t1.id=t2.id…。