互聯(lián)網(wǎng)Mysql數(shù)據(jù)庫應(yīng)用潛規(guī)則
軍規(guī)適用場(chǎng)景:并發(fā)量大仪媒、數(shù)據(jù)量大的互聯(lián)網(wǎng)業(yè)務(wù)
軍規(guī):介紹內(nèi)容
解讀:講解原因匈子,解讀比軍規(guī)更重要
一尤慰、基礎(chǔ)規(guī)范
(1)必須使用InnoDB存儲(chǔ)引擎
解讀:支持事務(wù)关斜、行級(jí)鎖叽粹、并發(fā)性能更好炭菌、CPU及內(nèi)存緩存頁優(yōu)化使得資源利用率更高
(2)必須使用UTF8字符集
解讀:萬國(guó)碼罪佳,無需轉(zhuǎn)碼,無亂碼風(fēng)險(xiǎn)黑低,節(jié)省空間
(3)數(shù)據(jù)表赘艳、數(shù)據(jù)字段必須加入中文注釋
解讀:N年后誰tm知道這個(gè)r1,r2,r3字段是干嘛的
(4)禁止使用存儲(chǔ)過程酌毡、視圖、觸發(fā)器蕾管、Event
解讀:高并發(fā)大數(shù)據(jù)的互聯(lián)網(wǎng)業(yè)務(wù)枷踏,架構(gòu)設(shè)計(jì)思路是“解放數(shù)據(jù)庫CPU,將計(jì)算轉(zhuǎn)移到服務(wù)層”掰曾,并發(fā)量大的情況下旭蠕,這些功能很可能將數(shù)據(jù)庫拖死,業(yè)務(wù)邏輯放到服務(wù)層具備更好的擴(kuò)展性旷坦,能夠輕易實(shí)現(xiàn)“增機(jī)器就加性能”掏熬。數(shù)據(jù)庫擅長(zhǎng)存儲(chǔ)與索引,CPU計(jì)算還是上移吧
(5)禁止存儲(chǔ)大文件或者大照片
解讀:為何要讓數(shù)據(jù)庫做它不擅長(zhǎng)的事情秒梅?大文件和照片存儲(chǔ)在文件系統(tǒng)旗芬,數(shù)據(jù)庫里存URI多好
二、命名規(guī)范
(6)只允許使用內(nèi)網(wǎng)域名捆蜀,而不是ip連接數(shù)據(jù)庫
(7)線上環(huán)境疮丛、開發(fā)環(huán)境、測(cè)試環(huán)境數(shù)據(jù)庫內(nèi)網(wǎng)域名遵循命名規(guī)范
業(yè)務(wù)名稱:xxx
線上環(huán)境:dj.xxx.db
開發(fā)環(huán)境:dj.xxx.rdb
測(cè)試環(huán)境:dj.xxx.tdb
從庫在名稱后加-s標(biāo)識(shí)漱办,備庫在名稱后加-ss標(biāo)識(shí)
線上從庫:dj.xxx-s.db
線上備庫:dj.xxx-sss.db
(8)庫名这刷、表名、字段名:小寫娩井,下劃線風(fēng)格暇屋,不超過32個(gè)字符,必須見名知意洞辣,禁止拼音英文混用
(9)表名t_xxx咐刨,非唯一索引名idx_xxx,唯一索引名uniq_xxx
三扬霜、表設(shè)計(jì)規(guī)范
(10)單實(shí)例表數(shù)目必須小于500
(11)單表列數(shù)目必須小于30
(12)表必須有主鍵定鸟,例如自增主鍵
解讀:
a)主鍵遞增,數(shù)據(jù)行寫入可以提高插入性能著瓶,可以避免page分裂联予,減少表碎片提升空間和內(nèi)存的使用
b)主鍵要選擇較短的數(shù)據(jù)類型, Innodb引擎普通索引都會(huì)保存主鍵的值材原,較短的數(shù)據(jù)類型可以有效的減少索引的磁盤空間沸久,提高索引的緩存效率
c) 無主鍵的表刪除,在row模式的主從架構(gòu)余蟹,會(huì)導(dǎo)致備庫夯住
(13)禁止使用外鍵約束卷胯,可以冗余外鍵,如果有外鍵完整性約束威酒,需要應(yīng)用程序控制
解讀:外鍵會(huì)導(dǎo)致表與表之間耦合窑睁,update與delete操作都會(huì)涉及相關(guān)聯(lián)的表挺峡,十分影響sql 的性能,甚至?xí)斐伤梨i担钮。高并發(fā)情況下容易造成數(shù)據(jù)庫性能橱赠,大數(shù)據(jù)高并發(fā)業(yè)務(wù)場(chǎng)景數(shù)據(jù)庫使用以性能優(yōu)先
四、字段設(shè)計(jì)規(guī)范
(14)必須把字段定義為NOT NULL并且提供默認(rèn)值
解讀:
a)null的列使索引/索引統(tǒng)計(jì)/值比較都更加復(fù)雜箫津,對(duì)MySQL來說更難優(yōu)化
b)null 這種類型MySQL內(nèi)部需要進(jìn)行特殊處理病线,增加數(shù)據(jù)庫處理記錄的復(fù)雜性;同等條件下鲤嫡,表中有較多空字段的時(shí)候送挑,數(shù)據(jù)庫的處理性能會(huì)降低很多
c)null值需要更多的存儲(chǔ)空,無論是表還是索引中每行中的null的列都需要額外的空間來標(biāo)識(shí)
d)對(duì)null 的處理時(shí)候暖眼,只能采用is null或is not null惕耕,而不能采用=、in诫肠、<司澎、<>、!=栋豫、not in這些操作符號(hào)挤安。如:where name!=’shenjian’,如果存在name為null值的記錄丧鸯,查詢結(jié)果就不會(huì)包含name為null值的記錄
(15)禁止使用TEXT蛤铜、BLOB類型
解讀:會(huì)浪費(fèi)更多的磁盤和內(nèi)存空間,非必要的大量的大字段查詢會(huì)淘汰掉熱數(shù)據(jù)丛肢,導(dǎo)致內(nèi)存命中率急劇降低围肥,影響數(shù)據(jù)庫性能
(16)禁止使用小數(shù)存儲(chǔ)貨幣
解讀:使用整數(shù)吧,小數(shù)容易導(dǎo)致錢對(duì)不上
(17)必須使用varchar(20)存儲(chǔ)手機(jī)號(hào)
解讀:
a)涉及到區(qū)號(hào)或者國(guó)家代號(hào)蜂怎,可能出現(xiàn)+-()
b)手機(jī)號(hào)會(huì)去做數(shù)學(xué)運(yùn)算么穆刻?
c)varchar可以支持模糊查詢,例如:like“138%”
(18)禁止使用ENUM杠步,可使用TINYINT代替
解讀:
a)增加新的ENUM值要做DDL操作
b)ENUM的內(nèi)部實(shí)際存儲(chǔ)就是整數(shù)氢伟,你以為自己定義的是字符串?
五幽歼、索引設(shè)計(jì)規(guī)范
(19)單表索引建議控制在5個(gè)以內(nèi)
(20)單索引字段數(shù)不允許超過5個(gè)
解讀:字段超過5個(gè)時(shí)朵锣,實(shí)際已經(jīng)起不到有效過濾數(shù)據(jù)的作用了
(21)禁止在更新十分頻繁、區(qū)分度不高的屬性上建立索引
解讀:
a)更新會(huì)變更B+樹试躏,更新頻繁的字段建立索引會(huì)大大降低數(shù)據(jù)庫性能
b)“性別”這種區(qū)分度不大的屬性猪勇,建立索引是沒有什么意義的设褐,不能有效過濾數(shù)據(jù)颠蕴,性能與全表掃描類似
(22)建立組合索引泣刹,必須把區(qū)分度高的字段放在前面
解讀:能夠更加有效的過濾數(shù)據(jù)
六、SQL使用規(guī)范
(23)禁止使用SELECT *犀被,只獲取必要的字段椅您,需要顯示說明列屬性
解讀:
a)讀取不需要的列會(huì)增加CPU、IO寡键、NET消耗
b)不能有效的利用覆蓋索引
c)使用SELECT *容易在增加或者刪除字段后出現(xiàn)程序BUG
(24)禁止使用INSERT INTO t_xxx VALUES(xxx)掀泳,必須顯示指定插入的列屬性
解讀:容易在增加或者刪除字段后出現(xiàn)程序BUG
(25)禁止使用屬性隱式轉(zhuǎn)換
解讀:SELECT uid FROM t_user WHERE phone=13812345678 會(huì)導(dǎo)致全表掃描,而不能命中phone索引西轩,猜猜為什么员舵?(這個(gè)線上問題不止出現(xiàn)過一次)
(26)禁止在WHERE條件的屬性上使用函數(shù)或者表達(dá)式
解讀:SELECT uid FROM t_user WHERE from_unixtime(day)>='2017-02-15' 會(huì)導(dǎo)致全表掃描
正確的寫法是:SELECT uid FROM t_user WHERE day>= unix_timestamp('2017-02-15 00:00:00')
(27)禁止負(fù)向查詢,以及%開頭的模糊查詢
解讀:
a)負(fù)向查詢條件:NOT藕畔、!=马僻、<>、!<注服、!>韭邓、NOT IN、NOT LIKE等溶弟,會(huì)導(dǎo)致全表掃描
b)%開頭的模糊查詢女淑,會(huì)導(dǎo)致全表掃描
(28)禁止大表使用JOIN查詢,禁止大表使用子查詢
解讀:會(huì)產(chǎn)生臨時(shí)表辜御,消耗較多內(nèi)存與CPU鸭你,極大影響數(shù)據(jù)庫性能
(29)禁止使用OR條件,必須改為IN查詢
解讀:舊版本Mysql的OR查詢是不能命中索引的擒权,即使能命中索引苇本,為何要讓數(shù)據(jù)庫耗費(fèi)更多的CPU幫助實(shí)施查詢優(yōu)化呢?
(30)應(yīng)用程序必須捕獲SQL異常菜拓,并有相應(yīng)處理
總結(jié):大數(shù)據(jù)量高并發(fā)的互聯(lián)網(wǎng)業(yè)務(wù)瓣窄,極大影響數(shù)據(jù)庫性能的都不讓用,不讓用喲纳鼎。
補(bǔ)充:
軍規(guī):必須使用UTF8字符集
和DBA負(fù)責(zé)人確認(rèn)后俺夕,糾正為“新庫默認(rèn)使用utf8mb4字符集”。
這點(diǎn)感謝網(wǎng)友的提醒贱鄙,utf8mb4是utf8的超集劝贸,emoji表情以及部分不常見漢字在utf8下會(huì)表現(xiàn)為亂碼,故需要升級(jí)至utf8mb4逗宁。
默認(rèn)使用這個(gè)字符集的原因是:“標(biāo)準(zhǔn)映九,萬國(guó)碼,無需轉(zhuǎn)碼瞎颗,無亂碼風(fēng)險(xiǎn)”件甥,并不“節(jié)省空間”捌议。
一個(gè)潛在坑:阿里云上RDS服務(wù)如果要從utf8升級(jí)為utf8mb4,需要重啟實(shí)例引有,所以58到家并沒有把所有的數(shù)據(jù)庫升級(jí)成這個(gè)字符集瓣颅,而是“新庫默認(rèn)使用utf8mb4字符集”。
自搭的Mysql可以完成在線轉(zhuǎn)換譬正,而不需要重啟數(shù)據(jù)庫實(shí)例宫补。
軍規(guī):數(shù)據(jù)表、數(shù)據(jù)字段必須加入中文注釋
這一點(diǎn)應(yīng)該沒有疑問曾我。
不過也有朋友提出粉怕,加入注釋會(huì)方便黑客,建議“注釋寫在文檔里抒巢,文檔和數(shù)據(jù)庫同步更新”斋荞。這個(gè)建議根據(jù)經(jīng)驗(yàn)來說是不太靠譜的:
(1)不能怕bug就不寫代碼,怕黑客就不寫注釋虐秦,對(duì)吧平酿?
(2)文檔同步更新也不太現(xiàn)實(shí),還是把注釋寫好悦陋,代碼可讀性做好更可行蜈彼,互聯(lián)網(wǎng)公司的文檔管理?呆過互聯(lián)網(wǎng)公司的同學(xué)估計(jì)都清楚俺驶。
軍規(guī):禁止使用存儲(chǔ)過程幸逆、視圖、觸發(fā)器暮现、Event
軍規(guī):禁止使用外鍵还绘,如果有外鍵完整性約束,需要應(yīng)用程序控制
軍規(guī):禁止大表使用JOIN查詢栖袋,禁止大表使用子查詢
很多網(wǎng)友提出拍顷,這些軍規(guī)不合理,完全做到不可能塘幅。
如原文所述昔案,58到家數(shù)據(jù)庫30條軍規(guī)的背景是“并發(fā)量大、數(shù)據(jù)量大的互聯(lián)網(wǎng)業(yè)務(wù)”电媳,這類業(yè)務(wù)架構(gòu)設(shè)計(jì)的重點(diǎn)往往是吞吐量踏揣,性能優(yōu)先(和錢相關(guān)的少部分業(yè)務(wù)是一致性優(yōu)先),對(duì)數(shù)據(jù)庫性能影響較大的數(shù)據(jù)庫特性較少使用匾乓。這類場(chǎng)景的架構(gòu)方向是“解放數(shù)據(jù)庫CPU捞稿,把復(fù)雜邏輯計(jì)算放到服務(wù)層”,服務(wù)層具備更好的擴(kuò)展性,容易實(shí)現(xiàn)“增機(jī)器就擴(kuò)充性能”娱局,數(shù)據(jù)庫擅長(zhǎng)存儲(chǔ)與索引彰亥,勿讓數(shù)據(jù)庫背負(fù)過重的任務(wù)。
關(guān)于這個(gè)點(diǎn)铃辖,再有較真的柳巖小編就不回復(fù)了哈,任何事情都沒有百分之百猪叙,但58到家的數(shù)據(jù)庫使用確實(shí)沒有存儲(chǔ)過程娇斩、視圖、觸發(fā)器穴翩、外鍵犬第、用戶自定義函數(shù),針對(duì)業(yè)務(wù)特性設(shè)計(jì)架構(gòu)芒帕,等單庫吞吐量到了幾千上萬歉嗓,就明白這些軍規(guī)的重要性啦。
軍規(guī):只允許使用內(nèi)網(wǎng)域名背蟆,而不是ip連接數(shù)據(jù)庫
這一點(diǎn)應(yīng)該也沒有疑問鉴分。
不只是數(shù)據(jù)庫,緩存(memcache带膀、redis)的連接志珍,服務(wù)(service)的連接都必須使用內(nèi)網(wǎng)域名,機(jī)器遷移/平滑升級(jí)/運(yùn)維管理…太多太多的好處垛叨,如果朋友你還是采用ip直連的伦糯,趕緊升級(jí)到內(nèi)網(wǎng)域名吧。
軍規(guī):禁止使用小數(shù)存儲(chǔ)國(guó)幣
有朋友問存儲(chǔ)前乘以100嗽元,取出后除以100是否可行敛纲,個(gè)人建議“盡量少的使用除法”。
曾經(jīng)踩過這樣的坑剂癌,100元分3天攤銷淤翔,每天攤銷100/3元,結(jié)果得到3個(gè)33.33佩谷。后來實(shí)施對(duì)賬系統(tǒng)办铡,始終有幾分錢對(duì)不齊,郁悶了很久(不是幾分錢的事琳要,是業(yè)務(wù)方質(zhì)疑的眼神讓研發(fā)很不爽)寡具,最后發(fā)現(xiàn)是除法惹的禍。
解決方案:使用“分”作為單位稚补,這樣數(shù)據(jù)庫里就是整數(shù)了童叠。
案例:SELECT uid FROM t_user WHERE phone=13812345678 會(huì)導(dǎo)致全表掃描,而不能命中phone索引
這個(gè)坑大家沒踩過么?
phone是varchar類型厦坛,SQL語句帶入的是整形五垮,故不會(huì)命中索引,加個(gè)引號(hào)就好了:
SELECT uid FROM t_user WHERE phone=’13812345678’
軍規(guī):禁止使用負(fù)向查詢NOT杜秸、!=放仗、<>、!<撬碟、!>诞挨、NOT IN、NOT LIKE等呢蛤,會(huì)導(dǎo)致全表掃描
此軍規(guī)爭(zhēng)議比較大惶傻,部分網(wǎng)友反饋不這么做很多業(yè)務(wù)實(shí)現(xiàn)不了,稍微解釋一下:
一般來說其障,WHERE過濾條件不會(huì)只帶這么一個(gè)“負(fù)向查詢條件”银室,還會(huì)有其他過濾條件,舉個(gè)例子:查詢沈劍已完成訂單之外的訂單(好拗口):
SELECT oid FROM t_order WHERE uid=123 AND status != 1;
訂單表5000w數(shù)據(jù)励翼,但uid=123就會(huì)迅速的將數(shù)據(jù)量過濾到很少的級(jí)別(uid建立了索引)蜈敢,此時(shí)再接上一個(gè)負(fù)向的查詢條件就無所謂了,掃描的行數(shù)本身就會(huì)很少汽抚。
但如果要查詢所有已完成訂單之外的訂單:
SELECT oid FROM t_order WHERE status != 1;
這就掛了扶认,立馬CPU100%,status索引會(huì)失效殊橙,負(fù)向查詢導(dǎo)致全表掃描辐宾。
末了,除了《58到家數(shù)據(jù)庫30條軍規(guī)解讀》中提到的基礎(chǔ)規(guī)范膨蛮、命名規(guī)范叠纹、表設(shè)計(jì)規(guī)范、字段設(shè)計(jì)規(guī)范敞葛、索引設(shè)計(jì)規(guī)范誉察、SQL使用規(guī)范,還有一個(gè)行為規(guī)范的軍規(guī):
(31)禁止使用應(yīng)用程序配置文件內(nèi)的帳號(hào)手工訪問線上數(shù)據(jù)庫
(32)禁止非DBA對(duì)線上數(shù)據(jù)庫進(jìn)行寫操作惹谐,修改線上數(shù)據(jù)需要提交工單持偏,由DBA執(zhí)行,提交的SQL語句必須經(jīng)過測(cè)試
(33)分配非DBA以只讀帳號(hào)氨肌,必須通過VPN+跳板機(jī)訪問授權(quán)的從庫
(34)開發(fā)鸿秆、測(cè)試、線上環(huán)境隔離
為什么要制定行為規(guī)范的軍規(guī)呢怎囚,大伙的公司是不是有這樣的情況:
任何研發(fā)卿叽、測(cè)試都有連接線上數(shù)據(jù)庫的帳號(hào)?
是不是經(jīng)常有這類誤操作?
(1)本來只想update一條記錄考婴,where條件搞錯(cuò)贩虾,update了全部的記錄
(2)本來只想delete幾行記錄,結(jié)果刪多了沥阱,四下無人缎罢,再insert回去
(3)以為drop的是測(cè)試庫,結(jié)果把線上庫drop掉了
(4)以為操作的是分庫x考杉,結(jié)果SecureCRT開窗口太多策精,操作成了分庫y
(5)寫錯(cuò)配置文件,壓力測(cè)試壓到線上庫了奔则,生成了N多臟數(shù)據(jù)
…
無數(shù)的事情蛮寂,結(jié)果就是打電話給DBA蔽午,讓他們幫忙擦屁股易茬。
…
所謂的“業(yè)務(wù)靈活性”都是扯淡,為什么要有行為規(guī)范及老?不讓你帶刀抽莱,不是限制你,而是保護(hù)你的安全骄恶。要相信DBA是專業(yè)的食铐,讓專業(yè)的人干專業(yè)的事情。別把DBA看做你的對(duì)立面僧鲁,多和他們溝通業(yè)務(wù)場(chǎng)景虐呻,溝通請(qǐng)求讀寫比,溝通訪問模式寞秃,他們真的能幫助到你斟叼,這是我?guī)BA團(tuán)隊(duì)的一些感觸。
誰都可能刪除全庫春寿,能找回?cái)?shù)據(jù)的朗涩,真的只有DBA。