db軍規30條
一、基礎規範
(1)必須使用innodb儲存引擎 解讀:支援事務、行級鎖、併發效能更好、cpu及記憶體快取頁優化使得資源利 用率更高
(2)必須使用utf8mb4字符集 解讀:萬國碼，無需轉碼，無亂碼風險，節省空間
(3)資料表、資料字段必須加入中文注釋 解讀:n年後誰tm知道這個r1,r2,r3欄位是幹嘛的
(4)禁止使用儲存過程、檢視、觸發器、event
(5)禁止儲存大檔案或者大** 解讀:為何要讓資料庫做它不擅長的事情?大檔案和**儲存在檔案系統，數 據庫里存uri多好
二、命名規範
(6)庫名、表名、欄位名:小寫，下劃線風格，不超過32個字元，必須見名 知意，禁止拼音英文混用
(9)表名shop_*** or wx_xx，非唯一索引名idx_***，唯一索引名uniq_*** (業務作為前置 公⽤用的不不加 )
三、表設計規範 (10)單例項表數目必須小於500
(11)單表列數目必須小於30
(12)表必須有主鍵，例如自增主鍵
解讀: a)主鍵遞增，資料行寫入可以提高插入效能，可以避免page**，減少表碎 片提公升空間和記憶體的使用
b)主鍵要選擇較短的資料型別， innodb引擎普通索引都會儲存主鍵的值，較 短的資料型別可以有效的減少索引的磁碟空間，提高索引的快取效率
c) 無主鍵的表刪除，在row模式的主從架構，會導致備庫夯住
(13)禁止使用外來鍵，如果有外來鍵完整性約束，需要應用程式控制 解讀:外來鍵會導致表與表之間耦合，update與delete操作都會涉及相關聯的 表，十分影響sql 的效能，甚至會造成死鎖。高併發情況下容易造成資料庫性 能，大資料高併發業務場景資料庫使用以效能優先
四、字段設計規範
(14)必須把字段定義為not null並且提供預設值
解讀: a)null的列使索引/索引統計/值比較都更加複雜，對mysql來說更難優化 b)null 這種型別mysql內部需要進行特殊處理，增加資料庫處理記錄的複雜 性;同等條件下，表中有較多空字段的時候，資料庫的處理效能會降低很多 c)null值需要更多的儲存空，無論是表還是索引中每行中的null的列都需要額 外的空間來標識
d)對null 的處理時候，只能採用is null或is not null，而不能採用=、in、<、 <>、!=、not in這些操作符號。如:where name!=』shenjian』，如果存在name 為null值的記錄，查詢結果就不會包含name為null值的記錄
(15)禁止使用text、blob型別 解讀:會浪費更多的磁碟和記憶體空間，非必要的大量的大字段查詢會淘汰掉熱 資料，導致記憶體命中率急劇降低，影響資料庫效能
(16)盡量使用小數儲存貨幣 解讀:使用整數吧，小數容易導致錢對不上
(17)盡量使用varchar(20)儲存手機號
解讀: a)涉及到區號或者國家代號，可能出現±() b)手機號會去做數**算麼? c)varchar可以支援模糊查詢，例如:like「138%」
(18)禁止使用enum，可使用tinyint代替 解讀:
a)增加新的enum值要做ddl操作
五、索引設計規範 (19)單錶索引建議控制在5個以內
(20)單索引欄位數不允許超過5個 解讀:字段超過5個時，實際已經起不到有效過濾資料的作用了
(21)禁止在更新十分頻繁、區分度不高的屬性上建立索引
解讀:a)更新會變更b+樹，更新頻繁的字段建立索引會大大降低資料庫效能 b)「性別」這種區分度不大的屬性，建立索引是沒有什麼意義的，不能有效過濾 資料，效能與全表掃瞄類似
(22)建立組合索引，必須把區分度高的字段放在前面 解讀:能夠更加有效的過濾資料
六、sql使⽤用規範
(23)禁止使用select *，只獲取必要的字段，需要顯示說明列屬性 解讀:
a)讀取不需要的列會增加cpu、io、net消耗 b)不能有效的利用覆蓋索引
c)使用select *容易在增加或者刪除欄位後出現程式bug
(24)禁止使用insert into t_*** values(***)，必須顯示指定插入的列 屬性
解讀:容易在增加或者刪除欄位後出現程式bug
(25)禁止使用屬性隱式轉換
解讀:select uid from t_user where phone=13812345678 會導致全表 掃瞄，而不能命中phone索引，猜猜為什麼?(這個線上問題不止出現過一 次)
(26)禁止在where條件的屬性上使用函式或者表示式
解讀:select uid from t_user where from_unixtime(day)>=『2017-02-15』 會導致全表掃瞄
正確的寫法是:select uid from t_user where day>= unix_timestamp(『2017-02-15 00:00:00』)
(27)禁止負向查詢，以及%開頭的模糊查詢
解讀:a)負向查詢條件:not、!=、<>、!<、!>、not in、not like等，會導致全 表掃瞄
b)%開頭的模糊查詢，會導致全表掃瞄 (28)禁止大表使用join查詢，禁止大表使用子查詢
解讀:會產生臨時表，消耗較多記憶體與cpu，極大影響資料庫效能
(29)禁止使用or條件，必須改為in查詢 解讀:舊版本mysql的or查詢是不能命中索引的，即使能命中索引，為何要讓 資料庫耗費更多的cpu幫助實施查詢優化呢?
(30)應用程式必須捕獲sql異常，並有相應處理
資料庫 規範
使用一致的 敘述性的名稱。靈活使用空格和縮進來增強可讀性。儲存符合iso 8601標準的日期格式 yyyy mm dd hh mm ss.sssss 最好使用標準sql函式而不是特定 商的函式以提高可移植性。保證 簡潔明瞭並消除多餘的sql 比如非必要的引號或括號，或者可以推導出的多餘where語句...
資料庫規範
所有資料庫物件名稱必須使用小寫字母並用下劃線分割 mysql嚴格區分大小寫 所有資料庫物件名稱禁止使用mysql保留關鍵字 例如from date常見關鍵字 命名要做到見名識義，最好不要超過32個字元 臨時表以tmp為字首日期為字尾 備份表以bak為字首日期為字尾 所有儲存相同資料的列明和列型別必須...
資料庫規範
資料庫和表的字符集統一用utf8 mysql 用 utf8mb64 unicode ci 所有的表和字段都需要新增注釋 盡量控制單錶資料量的大小 盡量在 500w 以內 謹慎使用 mysql 分割槽表 盡量做到冷熱資料分離,減少表的寬度 禁止在表中建立預留字段 禁止在資料庫中儲存,檔案等大的二進位制...