(1)必須使用InnoDB存儲引擎html
解讀:支持事務、行級鎖、併發性能更好、CPU及內存緩存頁優化使得資源利用率更高mysql
(2)表字符集默認使用utf8,必要時候使用utf8mb4git
解讀:一、通用,無亂碼風險,漢字3字節,英文1字節。二、utf8mb4是utf8的超集,有存儲4字節例如表情符號時,使用它github
(3)數據表、數據字段必須加入中文註釋sql
解讀:N年後誰tm知道這個r1,r2,r3字段是幹嗎的數據庫
(4)禁止使用存儲過程、視圖、觸發器、Event緩存
解讀:一、對數據庫性能影響較大,互聯網業務,能讓站點層和服務層乾的事情,不要交到數據庫層。二、調試,排錯,遷移都比較困難,擴展性較差。架構
再劃個重點,高併發大數據的互聯網業務,架構設計思路是「解放數據庫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整數,禁止使用字符串做爲主鍵
解讀:一、主鍵要選擇較短的數據類型, Innodb引擎普通索引都會保存主鍵的值,較短的數據類型能夠有效的減小索引的磁盤空間,提升索引的緩存效率。二、 無主鍵的表刪除,在row模式的主從架構,會致使備庫夯住
(4)禁止使用外鍵,若是有外鍵完整性約束,須要應用程序控制
解讀:外鍵會致使表與表之間耦合,update與delete操做都會涉及相關聯的表,十分影響sql 的性能,甚至會形成死鎖。高併發狀況下容易形成數據庫性能,互聯網業務場景數據庫使用以性能優先
(5)建議將大字段,訪問頻度低的字段拆分到單獨的表中存儲,分離冷熱數據
(1)根據業務區分使用tinyint/int/bigint,分別會佔用1/4/8字節
(2)根據業務區分使用char/varchar
解讀:一、字段長度固定,或者長度近似的業務場景,適合使用char,可以減小碎片,查詢性能高。二、字段長度相差較大,或者更新較少的業務場景,適合使用varchar,可以減小空間
(3)必須把字段定義爲NOT NULL並設默認值
解讀:一、NULL的列使用索引,索引統計,值都更加複雜,MySQL更難優化 二、NULL須要更多的存儲空間 三、NULL只能採用IS NULL或者IS NOT NULL,而在=/!=/in/not in時有大坑,參見我以前寫的:mysql中不等於過濾null的問題
(4)禁止使用double存儲貨幣,推薦decimal
解讀:你就不擔憂錢對不上嗎
(5)使用varchar(20)存儲手機號,不要使用整數
解讀:一、牽扯到國家代號,可能出現+/-/()等字符,例如+86。 二、手機號不會用來作數學運算。三、varchar能夠模糊查詢,例如like ‘138%’
(1)單表索引建議控制在5個之內
(2)禁止在更新十分頻繁、區分度不高的屬性上創建索引
解讀:一、更新會變動B+樹,更新頻繁的字段創建索引會大大下降數據庫性能。二、「性別」這種區分度不大的屬性,創建索引是沒有什麼意義的,不能有效過濾數據,性能與全表掃描相似。通常來講,同值的數據超過表的百分之十五,那就不必建索引了
(3)創建組合索引,必須把區分度高的字段放在前面
解讀:理解組合索引最左前綴原則,避免重複建設索引,若是創建了(a,b,c),至關於創建了(a), (a,b), (a,b,c)
(1)禁止使用SELECT *,只獲取必要的字段
解讀:一、讀取不須要的列會增長cpu/io/內存/帶寬的消耗。二、指定字段能有效利用索引覆蓋。三、指定字段查詢,在表結構變動時,能保證對應用程序無影響
(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)禁止負向查詢,以及%開頭的模糊查詢
解讀:一、負向查詢條件:NOT、!=、<>、!<、!>、NOT IN、NOT LIKE等,會致使全表掃描。二、%開頭的模糊查詢,會致使全表掃描,注意像'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項目。
參考:架構師之路