共計 2518 個字符，預計需要花費 7 分鐘才能閱讀完成。

今天就跟大家聊聊有關 mysql 數(shù)據(jù)庫的規(guī)范有哪些，可能很多人都不太了解，為了讓大家更加了解，丸趣 TV 小編給大家總結了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

基礎規(guī)范

【建議】使用 InnoDB 存儲引擎

【強制】無特殊要求必須使用 UTF8 字符集

【強制】數(shù)據(jù)表、數(shù)據(jù)字段必須加入中文注釋

【強制】禁止使用存儲過程、視圖、觸發(fā)器、Event。特殊情況申請評審

【強制】不在數(shù)據(jù)庫做運算，cpu 計算務必移至業(yè)務層

命名規(guī)范

【建議】命名使用具有實際意義的英文詞匯、詞匯縮寫，詞匯之間使用下劃線分隔；

【強制】命名只能使用小寫英文字母、數(shù)字、下劃線，且必須英文字母開頭，下劃線為分割符，不能超過 32 個字符，數(shù)據(jù)庫對象名盡可能簡短。避免使用 MySQL 的保留字

【強制】普通表名命名規(guī)則為功能模塊前綴_+tablename（login_users）；臨時表：tmp 前綴 +tablename+ 8 位時間后綴（tmp_users_20170501）；備份表：bak 前綴 +tablename+ 8 位時間后綴（bak_users_20170501）；歸檔表命名規(guī)則：arch 前綴 +tablename+ 歸檔規(guī)則 (arch _users_2013）【強制】各表之間相同意義的字段必須同名，數(shù)據(jù)類型、長度、單位必須相同。

【強制】索引以 idx_開頭唯一索引以 uq_idx 開頭，后面跟索引所在字段名, 多單詞組成的列名，取盡可能代表意義的縮寫，如 t_user_contacts 表 member_id 和 friend_id 上的組合索引：idx _mid_fid,, 組合索引命名應注意字段順序。如在字段 member_id 和字段 user_id 上創(chuàng)建組合索引，則可以命名為 idx _uid_mid(userid, member_id)

常用約定：

【建議】序號列字段：以 id 為后綴，如：user_id 表示用戶編號

【建議】編碼字段：以 code 為后綴，如：cust_code 表示客戶編碼

【建議】布爾值字段：以“is_”前綴 + 字段描述 + 形容詞。如 member 表上表示為 enabled 的會員的列命名為 is_member_enabled。0：否；1：是

【強制】狀態(tài)字段：以“_status”為后綴，前面加業(yè)務邏輯名。如：用戶狀態(tài)可命名為 user_status，訂單狀態(tài)為 order_status 以此類推

表設計規(guī)范（***）

【強制】表設計必須有表主鍵，并且主鍵不能提供給外部系統(tǒng)，給外部系統(tǒng)的必須使用業(yè)務主鍵，如 user 表的業(yè)務主鍵設計，如下 id 表主鍵，自增，表主鍵不能像外部系統(tǒng)提供 xxx_id 為業(yè)務主鍵，使用 IdGenerater(id 生成工具類生成，見附件)，可以提供給外部系統(tǒng)，使用 bigint 存儲

【強制】表必須有主鍵，如果使用 auto_increment 作為自增主鍵，注意導出初始化腳本時不要設置起始值。

【強制】枚舉類型使用 tinyint 類型

【強制】單表字段數(shù)不要太多，最多不要大于 50 個，且盡可能的少用字符型數(shù)據(jù)類型

【強制】日期的數(shù)據(jù) (不包含時分秒的)，使用 int(11) 存儲（如，yyyy、yyyyMM、yyyyMMdd），時間的數(shù)據(jù)((包含時分秒的))，使用 datetime 存儲。

【強制】每個表都必須包含兩個保留字段：create_time（創(chuàng)建時間），update_time（最后修改時間）creater varchar(50)（創(chuàng)建人）,updater varchar(50)（修改人），設置為非空字段屬性。這兩個字段不包含額外的業(yè)務邏輯。

【強制】每個表設置 is_del（0 為未刪除，1 為刪除）標記位字段，設置為非空，默認為 0 的字段屬性，生產(chǎn)環(huán)境不允許物理刪除。特殊表再議

【強制】表和列定義的時候必須加上 comment，并能精確描述表和列的含義。類型、狀態(tài)等字段必須明確給出各個值代表的含義；金錢等計量字段必須給出精確的計量單位；外鍵字段必須明確給出關聯(lián)的表和字段

【強制】若需要 JOIN 的字段（連接鍵），字段名稱、數(shù)據(jù)類型、長度和單位必須保持絕對一致，避免隱式轉換

【強制】禁止使用 TEXT、BLOB 類型（大文本、大文件、大照片存放在文件系統(tǒng)），可以把文件放到文件服務器中，數(shù)據(jù)庫只存 url

【強制】不推薦使用 enum，set。因為它們浪費空間，且枚舉值寫死了，變更不方便。推薦使用 tinyint 或 smallint

【強制】如果有業(yè)務流轉的加字段：業(yè)務流水號

【強制】如果一次操作多張表需要查看修改或者回退操作的，加操作流水號

【強制】禁止創(chuàng)建外鍵約束，外鍵約束由應用程序控制。外鍵會導致表與表之間耦合，update 與 delete 操作都會涉及相關聯(lián)的表，影響 sql 的性能，甚至會造成死鎖。

【強制】排序字段都不允許為空，并設置默認值。

字段設計規(guī)范

【強制】字符串類型一律使用 VARCHAR 類型，對于明確長度的建議使用 char，如身份證號等

【強制】禁止使用 TEXT、BLOB 類型。會浪費更多的磁盤和內(nèi)存空間，非必要的大量的大字段查詢會淘汰掉熱數(shù)據(jù)，導致內(nèi)存命中率急劇降低，影響數(shù)據(jù)庫性能

【建議】字段定義為 NOT NULL 并且提供默認值。null 的列使索引 / 索引統(tǒng)計 / 值比較都更加復雜，對 MySQL 來說更難優(yōu)化；需要更多的存儲空；只能采用 is null 或 is not null，而不能采用 =、in、= 2017-02-15 — 正確的寫法是：SELECT uid FROM t_user WHERE day = xxxfunc (2017-02-15 00:00:00)

【強制】禁止使用 OR 條件。使用 IN 或者 UINON 代替

【強制】禁止大表使用 JOIN 查詢，禁止大表使用子查詢。極大影響數(shù)據(jù)庫性能

【強制】禁止負向查詢，以及 % 開頭的模糊查詢。a）負向查詢條件：NOT、!=、、!、NOT IN、NOT LIKE 等，會導致全表掃描 b）% 開頭的模糊查詢，會導致全表掃描

【強制】使用 IN 不能超過 200

【建議】UNION ALL 代替 UNION 操作。

【建議】order by 的順序盡量與索引保持一致

【強制】大批量更新凌晨操作，避開高峰

看完上述內(nèi)容，你們對 mysql 數(shù)據(jù)庫的規(guī)范有哪些有進一步的了解嗎？如果還想了解更多知識或者相關內(nèi)容，請關注丸趣 TV 行業(yè)資訊頻道，感謝大家的支持。