MySQL資料庫設計規範
目錄

1. 規範背景與目的

2. 設計規範

2.1 資料庫設計

2.1.1 庫名
2.1.2 表結構
2.1.3 列資料型別優化
2.1.4 索引設計
2.1.5 分庫分表、分割槽表
2.1.6 字符集
2.1.7 程式DAO層設計建議
2.1.8 一個規範的建表語句示例

2.2 SQL編寫

2.2.1 DML語句
2.2.2 多表連線
2.2.3 事務
2.2.4 排序和分組
2.2.5 線上禁止使用的SQL語句

1. 規範背景與目的
   MySQL資料庫與 Oracle、 SQL Server 等資料庫相比，有其核心上的優勢與劣勢。我們在使用MySQL資料庫的時候需要遵循一定規範，揚長避短。本規範旨在幫助或指導RD、QA、OP等技術人員做出適合線上業務的資料庫設計。在資料庫變更和處理流程、資料庫表設計、SQL編寫等方面予以規範，從而為公司業務系統穩定、健康地執行提供保障。

2. 設計規範
   2.1 資料庫設計
   以下所有規範會按照【高危】、【強制】、【建議】三個級別進行標註，遵守優先順序從高到低。

對於不滿足【高危】和【強制】兩個級別的設計，DBA會強制打回要求修改。

2.1.1 庫名
【強制】庫的名稱必須控制在32個字元以內，相關模組的表名與表名之間儘量提現join的關係，如user表和user_login表。
【強制】庫的名稱格式：業務系統名稱_子系統名，同一模組使用的表名儘量使用統一字首。
【強制】一般分庫名稱命名格式是庫通配名_編號，編號從0開始遞增，比如wenda_001以時間進行分庫的名稱格式是“庫通配名_時間”
【強制】建立資料庫時必須顯式指定字符集，並且字符集只能是utf8或者utf8mb4。建立資料庫SQL舉例：create database db1 default character set utf8;。

2.1.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會產生表鎖，期間阻塞對於該表的所有寫入，對於業務可能會產生極大影響。
2.1.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()來進行轉換。
詳細儲存大小參加下圖：

MySQL資料型別儲存大小

2.1.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)為冗餘索引，需要刪除。
2.1.5 分庫分表、分割槽表
【強制】分割槽表的分割槽欄位（partition-key）必須有索引，或者是組合索引的首列。
【強制】單個分割槽表中的分割槽（包括子分割槽）個數不能超過1024。
【強制】上線前RD或者DBA必須指定分割槽表的建立、清理策略。
【強制】訪問分割槽表的SQL必須包含分割槽鍵。
【建議】單個分割槽檔案不超過2G，總大小不超過50G。建議總分割槽數不超過20個。
【強制】對於分割槽表執行alter table操作，必須在業務低峰期執行。
【強制】採用分庫策略的，庫的數量不能超過1024
【強制】採用分表策略的，表的數量不能超過4096
【建議】單個分表不超過500W行，ibd檔案大小不超過2G，這樣才能讓資料分散式變得效能更佳。
【建議】水平分表儘量用取模方式，日誌、報表類資料建議採用日期進行分表。
2.1.6 字符集
【強制】資料庫本身庫、表、列所有字符集必須保持一致，為utf8或utf8mb4。
【強制】前端程式字符集或者環境變數中的字符集，與資料庫、表的字符集必須一致，統一為utf8。
2.1.7 程式層DAO設計建議
【建議】新的程式碼不要用model，推薦使用手動拼SQL+繫結變數傳入引數的方式。因為model雖然可以使用面向物件的方式操作db，但是其使用不當很容易造成生成的SQL非常複雜，且model層自己做的強制型別轉換效能較差，最終導致資料庫效能下降。
【建議】前端程式連線MySQL或者redis，必須要有連線超時和失敗重連機制，且失敗重試必須有間隔時間。
【建議】前端程式報錯裡儘量能夠提示MySQL或redis原生態的報錯資訊，便於排查錯誤。
【建議】對於有連線池的前端程式，必須根據業務需要配置初始、最小、最大連線數，超時時間以及連接回收機制，否則會耗盡資料庫連線資源，造成線上事故。
【建議】對於log或history型別的表，隨時間增長容易越來越大，因此上線前RD或者DBA必須建立表資料清理或歸檔方案。
【建議】在應用程式設計階段，RD必須考慮並規避資料庫中主從延遲對於業務的影響。儘量避免從庫短時延遲（20秒以內）對業務造成影響，建議強制一致性的讀開啟事務走主庫，或更新後過一段時間再去讀從庫。
【建議】多個併發業務邏輯訪問同一塊資料（innodb表）時，會在資料庫端產生行鎖甚至表鎖導致併發下降，因此建議更新類SQL儘量基於主鍵去更新。
【建議】業務邏輯之間加鎖順序儘量保持一致，否則會導致死鎖。
【建議】對於單表讀寫比大於10:1的資料行或單個列，可以將熱點資料放在快取裡（如mecache或redis），加快訪問速度，降低MySQL壓力。
2.1.8 一個規範的建表語句示例
一個較為規範的建表語句為：

CREATE TABLE user (
id bigint(11) NOT NULL AUTO_INCREMENT,
user_id bigint(11) NOT NULL COMMENT ‘使用者id’
username varchar(45) NOT NULL COMMENT '真實姓名',
email varchar(30) NOT NULL COMMENT ‘使用者郵箱’,
nickname varchar(45) NOT NULL COMMENT '暱稱',
avatar int(11) NOT NULL COMMENT '頭像',
birthday date NOT NULL COMMENT '生日',
sex tinyint(4) DEFAULT '0' COMMENT '性別',
short_introduce varchar(150) DEFAULT NULL COMMENT '一句話介紹自己，最多50個漢字',
user_resume varchar(300) NOT NULL COMMENT '使用者提交的簡歷存放地址',
user_register_ip int NOT NULL COMMENT ‘使用者註冊時的源ip’,
create_time timestamp NOT NULL COMMENT ‘使用者記錄建立的時間’,
update_time timestamp NOT NULL COMMENT ‘使用者資料修改的時間’,
user_review_status tinyint NOT NULL COMMENT ‘使用者資料稽核狀態，1為通過，2為稽核中，3為未通過，4為還未提交稽核’,
PRIMARY KEY (id),
UNIQUE KEY idx_user_id (user_id),
KEY idx_username(username),
KEY idx_create_time(create_time,user_review_status)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='網站使用者基本資訊';
2.2 SQL編寫
2.2.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.2.2 多表連線
【強制】禁止跨db的join語句。因為這樣可以減少模組間耦合，為資料庫拆分奠定堅實基礎。
【強制】禁止在業務的更新類SQL語句中使用join，比如update t1 join t2…。
【建議】不建議使用子查詢，建議將子查詢SQL拆開結合程式多次查詢，或使用join來代替子查詢。
【建議】線上環境，多表join不要超過3個表。
【建議】多表連線查詢推薦使用別名，且SELECT列表中要用別名引用欄位，資料庫.表格式，如select a from db1.table1 alias1 where …。
【建議】在多表join中，儘量選取結果集較小的表作為驅動表，來join其他表。
2.2.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語句，請開啟事務強制訪問主庫。
2.2.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會很慢。
2.2.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…。

來源：