1 命名規范

1、【強制】庫名、表名、欄位名必須使用小寫字母并采用下劃線分割，禁止拼音英文混用；（禁用-，-相當于運算子）

2、【建議】庫名、表名、欄位名在滿足業務需求的條件下使用最小長度；

如information --> info；address --> addr等

3、【強制】庫名、表名、欄位名禁止使用MySQL保留關鍵字，如from,table等

詳見https://dev.mysql.com/doc/refman/5.7/en/keywords.html

4、【強制】臨時庫、臨時表名必須以tmp為前綴并以日期為后綴，例如tmp_user_20201231;

5、【強制】備份庫、備份表名必須以bak為前綴并以日期為后綴，例如bak_user_20201231;

6、【強制】非唯一索引命名idx_欄位1_欄位名2，唯一索引uniq_欄位名1_欄位名2；

2 基本規范

1、【強制】使用INNODB存盤引擎

支持事務、行級鎖、并發性能更好、CPU及記憶體快取頁優化使得資源利用率更高；

2、【強制】使用UTF8或UTF8MB4字符集;

萬國碼，無需轉碼，無亂碼風險，節省空間；

3、【強制】表、欄位必須有comments（中文注釋）;

中文注釋資訊必須保證完整、明確和準確；表和欄位含義發生變更時，comments（中文注釋）必須做同步修改；

4、【強制】不在資料庫中存盤圖片、檔案等大資料；

系統對資料庫的讀/寫速度 < 系統對檔案的直接處理速度

資料庫對大資料欄位的處理，效率不高

5、【強制】禁止在線上做資料庫壓力測驗；

6、【強制】禁止使用存盤程序、視圖、觸發器、Event;

跨庫查詢，視圖等可以考慮用寬表查詢

3 庫表設計規范

1、【強制】表必須有主鍵，例如自增主鍵，使用int或bigint，具體看預估業務量；

主鍵遞增，資料行寫入可以提高插入性能，可以避免page分裂，減少表碎片提升空間和記憶體的使用；

主鍵要選擇較短的資料型別， Innodb引擎普通索引都會保存主鍵的值，較短的資料型別可以有效的減少索引的磁盤空間，提高索引的快取效率；

無主鍵的表洗掉，在row模式的主從架構，會導致備庫夯住；

2、【建議】單表欄位數目建議不要過多，建議不要超過64

單表欄位數太多會使得MySQL處理InnoDB回傳資料之間的映射成本太高，

3、【強制】禁止使用外鍵，如果有外鍵完整性約束，需要應用程式控制

外鍵用來保護參照完整性，可在業務端實作，對父表和子表的操作會相互影響，降低可用性，甚至會造成死鎖，

4.【建議】所有表要有如下系統欄位，且按照如下順序

4 索引設計規范

索引是一把雙刃劍，它可以提高查詢效率但也會降低插入和更新的速度并占用磁盤空間

1、【建議】單張表中索引數量不超過5個（不包括主鍵）

索引不是越多越好，按實際需要進行創建，每個額外的索引都要占用額外的磁盤空間，并降低寫操作的性能；

2、【建議】單個索引中的欄位數不超過5個

對字串使用前綴索引，前綴索引長度不超過10個字符；如果有一個CHAR(200)列，如果在前10個字符內，多數值是惟一的，那么就不要對整個列進行索引，對前10個字符進行索引能夠節省大量索引空間，也可能會使查詢更快；

3、【強制】創建復合索引時, 必須把區分度高的欄位放在前面

4、【建議】不建議在更新十分頻繁、區分度不高的屬性上建立索引，特殊場景除外，例如只有0和1，1只占非常小的部分，只會去查詢1的情況，

5、【強制】避免冗余或重復索引

合理創建聯合索引（避免冗余），index(a、b、c)相當于index(a)、index(a、b)、index(a、b、c)；

5 欄位設計規范

1、【建議】不建議使用TEXT、BLOB型別

會浪費更多的磁盤和記憶體空間，非必要的大量的大欄位查詢會淘汰掉熱資料，導致記憶體命中率急劇降低，影響資料庫性能；如果實在有某個欄位過長需要使用 TEXT、BLOB 型別，則建議獨立出來一張表，用主鍵來對應，避免影響原表的查詢效率，

2、【強制】用DECIMAL代替FLOAT和DOUBLE存盤精確浮點數

浮點數相對于定點數的優點是在長度一定的情況下，浮點數能夠表示更大的資料范圍；浮點數的缺點是會引起精度問題

3、【強制】欄位必須定義合適的資料型別

只存盤數字的欄位定義成數字型別，只存盤字符的欄位定義成字符型別, 定長的字符定義成char ，盡可能用存盤空間小的型別，只存盤日期的欄位定義成日期型別，以減少使用程序中的資料型別轉換

4、【強制】禁止使用ENUM，可使用TINYINT代替

增加新的ENUM值要做DDL操作

5、【建議】欄位長度盡量按實際需要進行分配，不要隨意分配一個很大的容量

VARCHAR(N)，N表示的是字符數不是位元組數，比如VARCHAR(255)，可以最大可存盤255個漢字，需要根據實際的寬度來選擇N；

VARCHAR(N)，N盡可能小，因為MySQL一個表中所有的VARCHAR欄位最大長度是65535個位元組，進行排序和創建臨時表一類的記憶體操作時，會使用N的長度申請記憶體；

6、【建議】如果可能的話所有欄位均定義為not null且提供默認值

null的列使索引/索引統計/值比較都更加復雜，對MySQL來說更難優化;

null 這種型別MySQL內部需要進行特殊處理，增加資料庫處理記錄的復雜性；同等條件下，表中有較多空欄位的時候，資料庫的處理性能會降低很多;

null值需要更多的存盤空間，無論是表還是索引中每行中的null的列都需要額外的空間來標識;

對null 的處理時候，只能采用is null或is not null，而不能采用=、in、<、<>、!=、not in這些運算子號，如：where name!=’shenjian’，如果存在name為null值的記錄，查詢結果就不會包含name為null值的記錄;

7、【建議】建議使用TIMESTAMP存盤時間. 因為TIMESTAMP使用4位元組，DATETIME使用8個位元組,同時TIMESTAMP具有自動賦值以及自動更新的特性，具體看業務需求，

6 SQL設計規范

1、【建議】使用預編譯陳述句prepared statement（針對jdbc及mybatis）

只傳引數，比傳遞SQL陳述句更高效，一次決議，多次使用，降低SQL注入概率；

2、【強制】禁止在WHERE條件的屬性上使用函式或者運算式

無法使用索引導致全表掃描；

3、【強制】避免隱式轉換（查詢條件左右兩側型別不匹配）

會導致索引失效而全表掃描，如userid為int型別，select userid from table where userid='1234';相當于隱式地使用了函式將int型別轉換為字串，

4、【強制】禁止使用INSERT INTO t_xxx VALUES (xxx)，必須顯示指定插入的列屬性，否則容易在增加或者洗掉欄位后出現程式bug，

5、【強制】禁止使用SELECT *，只獲取必要的欄位，需要顯示說明列屬性

讀取不需要的列會增加CPU、IO、NET消耗，不能有效的利用覆寫索引，減少表結構變更帶來的影響；

6、【建議】避免使用大表的join, 大表使用子查詢

MySQL最擅長的是單表的主鍵/二級索引查詢，大表join會產生臨時表，消耗較多記憶體與CPU，極大影響資料庫性能；

7、【建議】拒絕大SQL，拆分成小SQL

充分利用多核CPU；

8、【建議】考慮使用limit N，少用limit M, N，特別是大表或M比較大的時候

9、【建議】減少或避免排序，盡量利用索引本身的有序 ，例如where條件中無id時order by id優化器會選擇主鍵索引，但是 where 條件里又沒有主鍵條件，導致全表掃描，

10、【建議】使用union all而不是union

盡量使用UNION  ALL，減少使用UNION，因為UNION  ALL不去重，而少了排序操作，速度相對比UNION要快，如果沒有去重的需求，優先使用UNION ALL；

11、【強制】避免使用全表掃描，配置表和小表（資料總量小于1萬條）例外，如果資料量比較小，或認為不會超過10000條資料，可以加上LIMIT限制；

12、【強制】同表的增刪欄位、索引合并一條DDL陳述句執行，提高執行效率，減少與資料庫的互動，

7 行為規范

1、【強制】大資料量匯入、匯出資料必須提前通知DBA協助觀察(以100w行作為參考基準，具體和表欄位數量相關)；

2、【強制】大資料量更新資料，如update、delete操作，需要DBA進行審查，并在執行程序中觀察服務負載等各種狀況；

3、【強制】禁止有super權限的應用程式賬號存在；

4、【強制】促銷活動或上線新功能必須提前一周通知DBA進行流量評估；

5、【強制】資料庫資料丟失，第一時間聯系DBA進行恢復；

6、【強制】不在MySQL資料庫中存放業務邏輯；

7、【強制】對特別重要的庫表，提前與DBA溝通確定維護和備份優先級；

8、【強制】不在業務高峰期批量更新、查詢資料庫；

標籤：其他

上一篇：云小課｜創建DDS只讀節點，輕松應對業務高峰

下一篇：SQLSERVER 的四個事務隔離級別到底怎么理解？