閱讀目錄

• 規范背景與目的
• 設計規范
• • 數據庫設計
  • 庫名
  • 表結構
  • 列數據類型優化
  • 索引設計
  • 分庫分表、分區表
  • 字符集
  • 一個規范的建表語句示例
• SQL 編寫
• • DML 語句
  • 多表連接
  • 事務
  • 排序和分組
  • 線上禁止使用的 SQL 語句

規范背景與目的

本規范旨在幫助或指導 RD、QA、OP 等技術人員做出適合線上業務的數據庫設計。在數據庫變更和處理流程、數據庫表設計、SQL編寫等方面予以規范，從而為公司業務系統穩定、健康地運行提供保障。

設計規范

數據庫設計

以下所有規范會按照【高危】、【強制】、【建議】三個級別進行標注，遵守優先級從高到低。

庫名

【強制】庫的名稱必須控制在32個字符以內，相關模塊的表名與表名之間盡量體現join的關系，如user表和user_login表。

【強制】庫的名稱格式：業務系統名稱_子系統名，同一模塊使用的庫名盡量使用統一前綴。

【強制】一般分庫名稱命名格式是庫通配名_編號，編號從0開始遞增，比如wenda_001以時間進行分庫的名稱格式是“庫通配名_時間”。

【強制】創建數據庫時必須顯式指定字符集，并且字符集只能是utf8或者utf8mb4。創建數據庫SQL舉例：create database db1 default character set utf8;

表結構

【強制】表必須有主鍵，且設置id為自增主鍵

---

【強制】表禁止使用外鍵，如果要保證完整下，應由程序端實現，外鍵使表之間相互耦合，影響 `update、delete` 等性能，有可能造成死鎖，高并發環境下容易導致數據庫性能瓶頸。

---

【強制】表和列的名稱必須控制在32個字符以內，表名只能使用字母、數字和下劃線，一律小寫。如表名過長可以采用縮寫等方式

---

【強制】創建表時必須顯式指定字符集為 `utf8` 或 `utf8mb4`

---

【強制】創建表時必須顯式指定表存儲引擎類型，如無特殊需求，一律為 `InnoDB`。當需要使用除 `InnoDB/MyISAM/Memory`以外的存儲引擎時，必須通過DBA審核才能在生產環境中使用。 因為`Innodb`表支持事務、行鎖、宕機恢復、MVCC等關系型數據庫重要特性，為業界使用最多的MySQL存儲引擎。而這是其他大多數存儲引擎不具備的，因此首推`InnoDB`

---

【強制】建表必須有`comment`，表級別和字段級別都要有`comment`

---

【建議】建表時關于主鍵： (1)強制要求主鍵為 `id`，類型為 `int` 或 `bigint`（為了以后延展性，這里要求新建表統一為 `bigint`），且為 `auto_increment` (2)標識表里每一行主體的字段不要設為主鍵，建議設為其他字段如 `user_id，order_id` 等，并建立`unique key`索引。因為如果設為主鍵且主鍵值為隨機插入，則會導致`innodb`內部`page`分裂和大量隨機I/O，性能下降

---

【建議】核心表（如用戶表，金錢相關的表）必須有行數據的創建時間字段 `create_time` 和最后更新時間字段 `update_time`，便于查問題

---

【建議】表中所有字段必須都是 `NOT NULL default `默認值 屬性，業務可以根據需要定義`DEFAULT`值。因為使用 `NULL` 值會存在每一行都會占用額外存儲空間、數據遷移容易出錯、聚合函數計算結果偏差以及索引失效等問題

---

【建議】建議對表里的 `blob、text` 等大字段，垂直拆分到其他表里，僅在需要讀這些對象的時候才去`select`

---

【建議】反范式設計：把經常需要 `join` 查詢的字段，在其他表里冗余一份。如`user_name`屬性在`user_account，user_login_log`等表里冗余一份，減少`join`查詢

---

【強制】中間表用于保留中間結果集，名稱必須以 `tmp_`開頭。備份表用于備份或抓取源表快照，名稱必須以 `bak_` 開頭。中間表和備份表定期清理

---

【強制】對于線上執行DDL變更，必須經過DBA審核，并由DBA在業務低峰期執行

---

列數據類型優化

【建議】表中的自增列（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溝通，是否真的需要這么大字段

---

【建議】存儲金錢的字段，建議用int，程序端乘以100和除以100進行存取。或者用decimal類型，而不要用double

---

【建議】文本數據盡量用varchar存儲。因為varchar是變長存儲，比char更省空間。MySQL server層規定一行所有文本最多存65535字節

---

【建議】時間類型盡量選取datetime。而timestamp雖然占用空間少，但是有時間范圍為1970-01-01 00:00:01到2038-01-01 00:00:00的問題（一般采用int類型存儲）

---

索引設計

【強制】InnoDB表必須主鍵為 id int/bigint auto_increment,且主鍵值禁止被更新

【建議】唯一鍵以“uk_”或“uq_”開頭，普通索引以“idx_”開頭，一律使用小寫格式，以字段的名稱或縮寫作為后綴

【強制】InnoDB和MyISAM存儲引擎表，索引類型必須為BTREE；MEMORY表可以根據需要選擇HASH或者BTREE類型索引

【強制】單個索引中每個索引記錄的長度不能超過64KB

【建議】單個表上的索引個數不能超過5個

【建議】在建立索引時，多考慮建立聯合索引，并把區分度最高的字段放在最前面。如列userid的區分度可由select count(distinct userid)計算出來

【建議】在多表join的SQL里，保證被驅動表的連接列上有索引，這樣join執行效率最高

【建議】建表或加索引時，保證表里互相不存在冗余索引。對于MySQL來說，如果表里已經存在key(a,b)，則key(a)為冗余索引，需要刪除

分庫分表、分區表

【強制】分區表的分區字段（partition-key）必須有索引，或者是組合索引的首列

【強制】單個分區表中的分區（包括子分區）個數不能超過1024

【強制】上線前RD或者DBA必須指定分區表的創建、清理策略

【強制】訪問分區表的SQL必須包含分區鍵

【建議】單個分區文件不超過2G，總大小不超過50G。建議總分區數不超過20個

【強制】對于分區表執行alter table操作，必須在業務低峰期執行

【強制】采用分庫策略的，庫的數量不能超過1024

【強制】采用分表策略的，表的數量不能超過4096

【建議】單個分表建議不超過500W行，這樣才能保證數據查詢性能更佳

【建議】水平分表盡量用取模方式，并預留出足夠的buffer，以免日后需要重新拆分和遷移，日志、報表類數據建議采用日期進行分表

字符集

【強制】數據庫本身庫、表、列所有字符集必須保持一致，為utf8或utf8mb4

【強制】前端程序字符集或者環境變量中的字符集，與數據庫、表的字符集必須一致，統一為utf8

一個規范的建表語句示例

CREATE TABLE user (`id` int(20) unsigned NOT NULL AUTO_INCREMENT,`user_id` int(20) unsigned NOT NULL default ‘0’ COMMENT ‘用戶id’,`username` varchar(45) NOT NULL default ‘’ COMMENT '真實姓名',`email` varchar(30) NOT NULL default ‘’COMMENT ‘用戶郵箱’,`nickname` varchar(45) NOT NULL default ‘’ COMMENT '昵稱',`avatar` int(11) NOT NULL default ‘0’ COMMENT '頭像',`birthday` date NOT NULL default ‘0000-00-00’ COMMENT '生日',`sex` tinyint(4) not null DEFAULT '0' COMMENT '性別',`short_introduce` varchar(150) not null DEFAULT ‘’COMMENT '一句話介紹自己，最多50個漢字',`user_resume` varchar(200) NOT NULL default ‘’COMMENT '用戶提交的簡歷存放地址',`user_register_ip` int NOT NULL COMMENT ‘用戶注冊時的源ip’,`created_at` datetime NOT NULL default current_timestamp COMMENT ‘用戶記錄創建的時間’,`updated_at` datetime default current_timestamp on update current_timestamp NOT NULL COMMENT ‘用戶資料修改的時間’,`user_review_status` tinyint NOT NULL default ‘1’ COMMENT ‘用戶資料審核狀態，1為通過，2為審核中，3為未通過，4為還未提交審核’,PRIMARY KEY (`id`),UNIQUE KEY `uq_user_id` (`user_id`),KEY `idx_username`(`username`),KEY `idx_create_time`(`create_time`,`user_review_status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='網站用戶基本信息';

SQL 編寫

DML 語句

【強制】SELECT語句必須指定具體字段名稱，禁止寫成*。因為select *會將不該讀的數據也從MySQL里讀出來，造成網卡壓力。且表字段一旦更新，但程序端沒有來得及更新的話，系統會報錯

---

【強制】insert語句指定具體字段名稱，不要寫成insert into t1 values(…)，道理同上

---

【建議】insert into…values(XX),(XX),(XX)…。這里XX的值不要超過500個。值過多雖然上線很很快，但會引起主從同步延遲

---

【建議】SELECT語句不要使用UNION，推薦使用UNION ALL，并且UNION子句個數限制在3個以內。因為union all不需要去重，節省數據庫資源，提高性能

---

【建議】in值列表限制在500以內。例如select… where userid in(….500個以內…)，這么做是為了減少底層掃描，減輕數據庫壓力從而加速查詢

---

【建議】事務里批量更新數據需要控制數量，進行必要的sleep，做到少量多次

---

【強制】事務涉及的表必須全部是innodb表。否則一旦失敗不會全部回滾，且易造成主從庫同步中斷

---

【強制】寫入和事務發往主庫，只讀SQL發往從庫，即程序端實現讀寫分離

---

【強制】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條件進行查找，如果要使用like，請使用like ‘xxxx%’的方式，必須有其他等值或范圍查詢條件，否則無法利用索引

---

【建議】索引列不要使用函數或表達式，否則無法利用索引。如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;

---

多表連接

【強制】禁止跨db的join語句。因為這樣可以減少模塊間耦合，為數據庫拆分奠定堅實基礎

【強制】禁止在業務的更新類SQL語句中使用join，比如update t1 join t2…

【建議】不建議使用子查詢，建議將子查詢SQL拆開結合程序多次查詢，或使用join來代替子查詢

【建議】線上環境，多表join不要超過3個表

【建議】多表連接查詢推薦使用別名，且SELECT列表中要用別名引用字段，數據庫.表格式，如select a from db1.table1 alias1 where …

【建議】在多表join中，盡量選取結果集較小的表作為驅動表，來join其他表

事務

【建議】事務中INSERT|UPDATE|DELETE|REPLACE語句操作的行數控制在1000以內，以及WHERE子句中IN列表的傳參個數控制在500以內

【建議】批量操作數據時，需要控制事務處理間隔時間，進行必要的sleep，一般建議值1-2秒

【建議】對于有auto_increment屬性字段的表的插入操作，并發需要控制在200以內

【強制】程序設計必須考慮“數據庫事務隔離級別”帶來的影響，包括臟讀、不可重復讀和幻讀。線上建議事務隔離級別為repeatable-read

【建議】事務里包含SQL不超過5個（支付業務除外）。因為過長的事務會導致鎖數據較久，MySQL內部緩存、連接消耗過多等雪崩問題

【建議】事務里更新語句盡量基于主鍵或unique key，如update … where id=XX; 否則會產生間隙鎖，內部擴大鎖定范圍，導致系統性能下降，產生死鎖

【建議】盡量把一些典型外部調用移出事務，如調用webservice，訪問文件存儲等，從而避免事務過長

【建議】對于MySQL主從延遲嚴格敏感的select語句，請開啟事務強制訪問主庫

排序和分組

【建議】減少使用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會很慢

線上禁止使用的 SQL 語句

【高危】禁用 update|delete t1 … where a=XX limit XX;這種帶limit的更新語句。如果是非row格式的binlog格式，會導致主從不一致，導致數據錯亂。建議加上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…、replace into等語句，在高并發環境下，極容易導致死鎖

【強制】禁止聯表更新語句，如update t1,t2 where t1.id=t2.id…

總結

以上是生活随笔為你收集整理的MySQL 设计与开发规范的全部內容，希望文章能夠幫你解決所遇到的問題。

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