第一條：必須使用InnoDB存儲引擎
解讀：支持事務(wù)、行級鎖、并發(fā)性能更好、CPU及內存緩存頁(yè)優(yōu)化使得資源利用率更高
第二條：必須使用utf8(utf8mb4)字符集
解讀：萬(wàn)國碼，無(wú)需轉碼，無(wú)亂碼風(fēng)險，節省空間，utf8mb4是utf8的超集，由于近年移動(dòng)設備的增多，emoji表情以及部分不常見(jiàn)漢字在utf8下會(huì )表現為亂碼，故需要升級至utf8mb4
第三條：數據表、數據字段必須加入中文注釋
解讀：N年后誰(shuí)會(huì )知道這個(gè)a1,a2,a3字段是干嘛的
第四條：禁止使用存儲過(guò)程、視圖、觸發(fā)器、Event
解讀：高并發(fā)大數據的互聯(lián)網(wǎng)業(yè)務(wù)，架構設計思路是“解放數據庫CPU，將計算轉移到服務(wù)層”，并發(fā)量大的情況下，這些功能很可能將數據庫拖死，業(yè)務(wù)邏輯放到服務(wù)層具備更好的擴展性，能夠輕易實(shí)現“增機器就加性能”。數據庫擅長(cháng)存儲與索引，CPU計算還是上移吧
第五條：禁止存儲大文件或者大照片
解讀：為何要讓數據庫做它不擅長(cháng)的事情？大文件和照片存儲在文件系統，數據庫里存URI多好
第一條：只允許使用內網(wǎng)域名，而不是ip連接數據庫
解讀：雖然IP訪(fǎng)問(wèn)更快，域名訪(fǎng)問(wèn)需要內網(wǎng)dns，但是對于大數據庫的擴展和遷庫考慮，域名更好
第二條：線(xiàn)上環(huán)境、開(kāi)發(fā)環(huán)境、測試環(huán)境數據庫內網(wǎng)域名遵循命名規范
業(yè)務(wù)名稱(chēng)：xxx線(xiàn)上環(huán)境：dj.xxx.db開(kāi)發(fā)環(huán)境：dj.xxx.rdb測試環(huán)境：dj.xxx.tdb從庫在名稱(chēng)后加-s標識，備庫在名稱(chēng)后加-ss標識線(xiàn)上從庫：dj.xxx-s.db線(xiàn)上備庫：dj.xxx-sss.db
第三條：庫名、表名、字段名：小寫(xiě)，下劃線(xiàn)風(fēng)格，不超過(guò)32個(gè)字符，禁止拼音英文混用
解讀：見(jiàn)名知意，方便后續維護
第四條：表名t_xxx，非唯一索引名idx_xxx，唯一索引名uniq_xxx
解讀：見(jiàn)名知意，方便后續維護
第一條：禁止使用外鍵，如果有外鍵完整性約束，需要應用程序控制
解讀：外鍵會(huì )導致表與表之間耦合，update與delete操作都會(huì )涉及相關(guān)聯(lián)的表，十分影響sql的性能，甚至會(huì )造成死鎖。高并發(fā)情況下容易造成數據庫性能，大數據高并發(fā)業(yè)務(wù)場(chǎng)景數據庫使用以性能優(yōu)先
第二條：必須把字段定義為NOT NULL并且提供默認值
解讀：a) null的列使索引/索引統計/值比較都更加復雜，對MySQL來(lái)說(shuō)更難優(yōu)化b) null這種類(lèi)型MySQL內部需要進(jìn)行特殊處理，增加數據庫處理記錄的復雜性；同等條件下，表中有較多空字段的時(shí)候，數據庫的處理性能會(huì )降低很多c) null值需要更多的存儲空，無(wú)論是表還是索引中每行中的null的列都需要額外的空間來(lái)標識d) 對null的處理時(shí)候，只能采用is null或is not null，而不能采用=、in、<、<>、!=、not in這些操作符號。如：where name!='shenjian'，如果存在name為null值的記錄，查詢(xún)結果就不會(huì )包含name為null值的記錄
第三條：禁止使用TEXT、BLOB類(lèi)型
解讀：會(huì )浪費更多的磁盤(pán)和內存空間，非必要的大量的大字段查詢(xún)會(huì )淘汰掉熱數據，導致內存命中率急劇降低，影響數據庫性能
第四條：禁止使用小數存儲國幣
解讀：曾經(jīng)踩過(guò)這樣的坑，100元分3天攤銷(xiāo)，每天攤銷(xiāo)(100/3)元，結果得到3個(gè)33.33。后來(lái)實(shí)施對賬系統，始終有幾分錢(qián)對不齊，郁悶了很久（不是幾分錢(qián)的事，是業(yè)務(wù)方質(zhì)疑的眼神讓研發(fā)很不爽），最后發(fā)現是除法惹的禍解決方案：使用“分”作為單位，這樣數據庫里就是整數了
第五條：必須使用varchar(20)存儲手機號
解讀：a) 涉及到區號或者國家代號，可能出現+-()b) 手機號會(huì )去做數學(xué)運算么？c) varchar可以支持模糊查詢(xún)，例如：like“138%”
第六條：禁止使用ENUM，可使用TINYINT代替
解讀：a) 增加新的ENUM值要做DDL操作b) ENUM的內部實(shí)際存儲就是整數，你以為自己定義的是字符串？
第七條：表必須有主鍵，例如自增主鍵
解讀：a) 主鍵遞增，數據行寫(xiě)入可以提高插入性能，可以避免page分裂，減少表碎片提升空間和內存的使用b) 主鍵要選擇較短的數據類(lèi)型， Innodb引擎普通索引都會(huì )保存主鍵的值，較短的數據類(lèi)型可以有效的減少索引的磁盤(pán)空間，提高索引的緩存效率c) 無(wú)主鍵的表刪除，在row模式的主從架構，會(huì )導致備庫夯住
第一條：?jiǎn)伪硭饕ㄗh控制在5個(gè)以?xún)?/p>
解讀：一個(gè)好的索引設計，可以讓你的效率提高幾十甚至幾百倍，但過(guò)多反而適得其反
第二條：?jiǎn)嗡饕侄螖挡辉试S超過(guò)5個(gè)
解讀：字段超過(guò)5個(gè)時(shí)，實(shí)際已經(jīng)起不到有效過(guò)濾數據的作用了
第三條：禁止在更新十分頻繁、區分度不高的屬性上建立索引
解讀：a) 更新會(huì )變更B+樹(shù)，更新頻繁的字段建立索引會(huì )大大降低數據庫性能b) "性別"這種區分度不大的屬性，建立索引是沒(méi)有什么意義的，不能有效過(guò)濾數據，性能與全表掃描類(lèi)似
第四條:建立組合索引，必須把區分度高的字段放在前面
解讀：能夠更加有效的過(guò)濾數據
第一條：禁止使用SELECT *，只獲取必要的字段，需要顯示說(shuō)明列屬性
解讀：a) 讀取不需要的列會(huì )增加CPU、IO、NET消耗b) 不能有效的利用覆蓋索引c) 使用SELECT *容易在增加或者刪除字段后出現程序BUG
第二條：禁止使用INSERT INTO t_xxx VALUES(xxx)，必須顯示指定插入的列屬性
解讀：容易在增加或者刪除字段后出現程序BUG
第三條：禁止使用屬性隱式轉換
解讀：SELECT uid FROM t_user WHERE phone=13812345678 會(huì )導致全表掃描，而不能命中phone索引，猜猜為什么？int數據類(lèi)型優(yōu)先級高于archer， 該查詢(xún)會(huì )把phone轉換為int，因此需要把表中所有數據改成int，所以必須全盤(pán)掃描phone是varchar類(lèi)型，SQL語(yǔ)句帶入的是整形，故不會(huì )命中索引，加個(gè)引號就好了：SELECT uid FROM t_user WHERE phone='13812345678'
第四條：禁止在WHERE條件的屬性上使用函數或者表達式
解讀：SELECT uid FROM t_user WHERE from_unixtime(day)>='2017-02-15' 會(huì )導致全表掃描正確的寫(xiě)法是：SELECT uid FROM t_user WHERE day>= unix_timestamp('2017-02-15 00:00:00')
第五條：禁止大表使用JOIN查詢(xún)，禁止大表使用子查詢(xún)
解讀：會(huì )產(chǎn)生臨時(shí)表，消耗較多內存與CPU，極大影響數據庫性能，大表指的是數據量在1000萬(wàn)以上的表
第六條：禁止使用OR條件，必須改為IN查詢(xún)
解讀：舊版本Mysql的OR查詢(xún)是不能命中索引的，即使能命中索引，為何要讓數據庫耗費更多的CPU幫助實(shí)施查詢(xún)優(yōu)化呢？
第七條：禁止使用負向查詢(xún)，以及%開(kāi)頭的模糊查詢(xún)
解讀：a) 負向查詢(xún)條件：NOT、!=、<>、!<、!>、NOT IN、NOT LIKE等，會(huì )導致全表掃描b) %開(kāi)頭的模糊查詢(xún)，會(huì )導致全表掃描一般來(lái)說(shuō)，WHERE過(guò)濾條件不會(huì )只帶這么一個(gè)“負向查詢(xún)條件”，還會(huì )有其他過(guò)濾條件，舉個(gè)例子：查詢(xún)沈劍已完成訂單之外的訂單（好拗口）：SELECT oid FROM t_order WHERE uid=123 AND status != 1;訂單表5000w數據，但uid=123就會(huì )迅速的將數據量過(guò)濾到很少的級別（uid建立了索引），此時(shí)再接上一個(gè)負向的查詢(xún)條件就無(wú)所謂了，掃描的行數本身就會(huì )很少但如果要查詢(xún)所有已完成訂單之外的訂單：SELECT oid FROM t_order WHERE status != 1;這就掛了，立馬CPU100%，status索引會(huì )失效，負向查詢(xún)導致全表掃描
第八條：應用程序必須捕獲SQL異常，并有相應處理
解讀：方便維護，及時(shí)“查漏補缺”
總結：大數據量高并發(fā)的互聯(lián)網(wǎng)業(yè)務(wù)，極大影響數據庫性能的都不讓用，不讓用喲。
聯(lián)系客服
