一、基礎規范

（1）必須使用InnoDB存儲引擎

解讀：支持事務、行級鎖、并發性能更好、CPU及內存緩存頁優化使得資源利用率更高

（2）表字符集默認使用utf8，必要時候使用utf8mb4

解讀：1、通用，無亂碼風險，漢字3字節，英文1字節。2、utf8mb4是utf8的超集，有存儲4字節例如表情符號時，使用它

（3）數據表、數據字段必須加入中文注釋

解讀：N年后誰tm知道這個r1,r2,r3字段是干嘛的

（4）禁止使用存儲過程、視圖、觸發器、Event

解讀：1、對數據庫性能影響較大，互聯網業務，能讓站點層和服務層干的事情，不要交到數據庫層。2、調試，排錯，遷移都比較困難，擴展性較差。

再劃個重點，高并發大數據的互聯網業務，架構設計思路是“解放數據庫CPU，將計算轉移到服務層”，并發量大的情況下，這些功能很可能將數據庫拖死，業務邏輯放到服務層具備更好的擴展性，能夠輕易實現“增機器就加性能”。數據庫擅長存儲與索引，CPU計算還是上移吧。

（5）禁止存儲大文件或者大照片

解讀：為何要讓數據庫做它不擅長的事情？大文件和照片存儲在文件系統，數據庫里存URI多好

二、命名規范

（1）庫名，表名，列名必須用小寫，采用下劃線分隔

解讀：abc，Abc，ABC都是給自己埋坑

?（2）庫名，表名，列名必須見名知義，長度不要超過32字符，禁止拼音英文混用

解讀：tmp，wushan誰TM知道這些庫是干嘛的

（3）表名t_xxx，非唯一索引名idx_xxx，唯一索引名uniq_xxx

（4）SQL語句中關鍵字大寫，并放在單獨的行開始

三、表設計規范

（1）單實例表數目必須小于2000個

（2）單表列數目必須小于80個

（3）表必須有主鍵，推薦使用UNSIGNED整數，禁止使用字符串作為主鍵

解讀：1、主鍵要選擇較短的數據類型，?Innodb引擎普通索引都會保存主鍵的值，較短的數據類型可以有效的減少索引的磁盤空間，提高索引的緩存效率。2、?無主鍵的表刪除，在row模式的主從架構，會導致備庫夯住

（4）禁止使用外鍵，如果有外鍵完整性約束，需要應用程序控制

解讀：外鍵會導致表與表之間耦合，update與delete操作都會涉及相關聯的表，十分影響sql?的性能，甚至會造成死鎖。高并發情況下容易造成數據庫性能，互聯網業務場景數據庫使用以性能優先

（5）建議將大字段，訪問頻度低的字段拆分到單獨的表中存儲，分離冷熱數據

四、字段設計規范

（1）根據業務區分使用tinyint/int/bigint，分別會占用1/4/8字節

（2）根據業務區分使用char/varchar

解讀：1、字段長度固定，或者長度近似的業務場景，適合使用char，能夠減少碎片，查詢性能高。2、字段長度相差較大，或者更新較少的業務場景，適合使用varchar，能夠減少空間

（3）必須把字段定義為NOT NULL并設默認值

解讀：1、NULL的列使用索引，索引統計，值都更加復雜，MySQL更難優化 2、NULL需要更多的存儲空間 3、NULL只能采用IS NULL或者IS NOT NULL，而在=/!=/in/not in時有大坑，參見我之前寫的：mysql中不等于過濾null的問題

（4）禁止使用double存儲貨幣,推薦decimal

解讀：你就不擔心錢對不上嗎

（5）使用varchar(20)存儲手機號，不要使用整數

解讀：1、牽扯到國家代號，可能出現+/-/()等字符，例如+86。 ?2、手機號不會用來做數學運算。3、varchar可以模糊查詢，例如like ‘138%’

五、索引設計規范

（1）單表索引建議控制在5個以內

（2）禁止在更新十分頻繁、區分度不高的屬性上建立索引

解讀：1、更新會變更B+樹，更新頻繁的字段建立索引會大大降低數據庫性能。2、“性別”這種區分度不大的屬性，建立索引是沒有什么意義的，不能有效過濾數據，性能與全表掃描類似。一般來說，同值的數據超過表的百分之十五，那就沒必要建索引了

（3）建立組合索引，必須把區分度高的字段放在前面

解讀：理解組合索引最左前綴原則，避免重復建設索引，如果建立了(a,b,c)，相當于建立了(a), (a,b), (a,b,c)

六、SQL使用規范

（1）禁止使用SELECT *，只獲取必要的字段

解讀：1、讀取不需要的列會增加cpu/io/內存/帶寬的消耗。2、指定字段能有效利用索引覆蓋。3、指定字段查詢，在表結構變更時，能保證對應用程序無影響

（2）禁止使用INSERT INTO t_xxx VALUES(xxx)，必須顯示指定插入的列屬性

解讀：容易在增加或者刪除字段后出現程序BUG

（3）禁止使用屬性隱式轉換

解讀：SELECT uid FROM t_user WHERE phone=13812345678?會導致全表掃描，而不能命中phone索引。這里應當對13812345678 加上單引號'13812345678?'。實際工作中類型字段的隱式轉換是最多的，需要特別注意。

（4）禁止在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')

（5）禁止負向查詢，以及%開頭的模糊查詢

解讀：1、負向查詢條件：NOT、!=、<>、!<、!>、NOT IN、NOT LIKE等，會導致全表掃描。2、%開頭的模糊查詢，會導致全表掃描，注意像'138%'也是會使用索引的。

（6）禁止大表使用JOIN查詢，禁止大表使用子查詢

解讀：會產生臨時表，消耗較多內存與CPU，極大影響數據庫性能

（7）禁止使用OR條件，必須改為IN查詢，IN的值必須少于50個

解讀：舊版本Mysql的OR查詢是不能命中索引的，即使能命中索引，為何要讓數據庫耗費更多的CPU幫助實施查詢優化呢？

（8）多表連接必須使用JOIN，LEFT?JOIN，禁止使用FROM tab1,tab2

解讀：都能實現關聯查詢，但是使用join更加靈活，效率更高。同時使用join會突出主表的存在，方便在mybaits等框架中快速定位sql位置。sql必須放在主表的xml中，便于重用。

結語：本規范將作為yyblog2.0數據庫的開發要求，后續會不斷更新。

yyblog1.0項目地址：https://github.com/allanzhuo/yyblog?歡迎star關注yyblog項目。

參考：架構師之路

轉載于:https://www.cnblogs.com/laoyeye/p/9925449.html

總結

以上是生活随笔為你收集整理的yyblog2.0 数据库开发规范的全部內容，希望文章能夠幫你解決所遇到的問題。

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