轉(zhuǎn)載 2018-03-30 58到家DBA 架構(gòu)師之路
一先壕、基礎(chǔ)規(guī)范
1. 表存儲引擎必須使用InnoDB
解讀：
- 支持事務吕粗，行級鎖
- 使用聚集索引
- 使用獨立表空間（5.6）
2. 表字符集默認使用utf8窟赏，必要時候使用utf8mb4
解讀：
4. 通用片部，無亂碼風險打颤，漢字3字節(jié)桨武，英文1字節(jié)
5. utf8mb4是utf8的超集财骨，有存儲4字節(jié)例如表情符號時镐作，使用它
3. 禁止使用存儲過程，視圖隆箩，觸發(fā)器该贾，Event
解讀：
- 對數(shù)據(jù)庫性能影響較大，互聯(lián)網(wǎng)業(yè)務捌臊，能讓站點層和服務層干的事情杨蛋，不要交到數(shù)據(jù)庫層
- 調(diào)試，排錯，遷移都比較困難逞力，擴展性較差
4. 禁止在數(shù)據(jù)庫中存儲大文件
例如照片曙寡，可以將大文件存儲在對象存儲系統(tǒng)，數(shù)據(jù)庫中存儲路徑
5. 禁止在線上環(huán)境做數(shù)據(jù)庫壓力測試
防止影響線上服務的正常運行
6. 測試寇荧，開發(fā)举庶，線上數(shù)據(jù)庫環(huán)境必須隔離
防止各各環(huán)境相互影響
二、命名規(guī)范
- 庫名揩抡，表名户侥，列名必須用小寫，采用下劃線分隔
解讀：abc峦嗤，Abc蕊唐，ABC都是給自己埋坑
- 庫名，表名烁设，列名必須見名知義替梨，長度不要超過32字符
解讀：tmp，wushan誰TM知道這些庫是干嘛的
- 庫備份必須以bak為前綴署尤，以日期為后綴
- 從庫必須以-s為后綴
- 備庫必須以-ss為后綴
三耙替、表設計規(guī)范
1. 單實例表個數(shù)必須控制在2000個以內(nèi)
2. 單表分表個數(shù)必須控制在1024個以內(nèi)
3. 表必須有主鍵，推薦使用UNSIGNED整數(shù)為主鍵
潛在坑：刪除無主鍵的表曹体，如果是row模式的主從架構(gòu)俗扇，從庫會掛住
4. 禁止使用外鍵，如果要保證完整性箕别，應由應用程式實現(xiàn)
解讀：
外鍵使得表之間相互耦合铜幽，影響update/delete等SQL性能，有可能造成死鎖串稀，高并發(fā)情況下容易成為數(shù)據(jù)庫瓶頸除抛。
例如一張表有3個外鍵，在進行數(shù)據(jù)新增的過程中母截，它會自動去關(guān)聯(lián)表驗證外鍵數(shù)據(jù)是否存在到忽，如果關(guān)聯(lián)表比較大就會造成較大的新能損耗。
5. 建議將大字段清寇，訪問頻度低的字段拆分到單獨的表中存儲喘漏，分離冷熱數(shù)據(jù)
解讀：具體參考《如何實施數(shù)據(jù)庫垂直拆分》
四、列設計規(guī)范
1. 根據(jù)業(yè)務區(qū)分
2. 使用tinyint/int/bigint华烟，分別會占用1/4/8字節(jié)
3. 根據(jù)業(yè)務區(qū)分使用char/varchar
解讀：
- 字段長度固定翩迈，或者長度近似的業(yè)務場景，適合使用char盔夜，能夠減少碎片负饲，查詢性能高
- 字段長度相差較大堤魁，或者更新較少的業(yè)務場景，適合使用varchar返十，能夠減少空間
4. 根據(jù)業(yè)務區(qū)分使用datetime/timestamp
解讀：前者占用5個字節(jié)妥泉，后者占用4個字節(jié)，存儲年使用YEAR吧慢，存儲日期使用DATE涛漂，存儲時間使用datetime
5. 必須把字段定義為NOT NULL并設默認值
解讀：
- NULL的列使用索引，索引統(tǒng)計检诗，值都更加復雜，MySQL更難優(yōu)化
- NULL需要更多的存儲空間
- NULL只能采用IS NULL或者IS NOT NULL瓢剿，而在=/!=/in/not in時有大坑
可以參考:https://xiaolyuh.blog.csdn.net/article/details/105427529
6. 使用INT UNSIGNED存儲IPv4逢慌，不要用char(15)
7. 使用varchar(20)存儲手機號，不要使用整數(shù)
解讀：
- 牽扯到國家代號间狂，可能出現(xiàn)+/-/()等字符攻泼，例如+86
- 手機號不會用來做數(shù)學運算
- varchar可以模糊查詢，例如like ‘138%’
8. 使用TINYINT來代替ENUM
解讀：ENUM增加新值要進行DDL操作
五鉴象、索引規(guī)范
唯一索引使用uniq_[字段名]來命名
非唯一索引使用idx_[字段名]來命名
單張表索引數(shù)量建議控制在5個以內(nèi)
解讀：
互聯(lián)網(wǎng)高并發(fā)業(yè)務忙菠，太多索引會影響寫性能
生成執(zhí)行計劃時，如果索引太多纺弊，會降低性能牛欢，并可能導致MySQL選擇不到最優(yōu)索引
異常復雜的查詢需求，可以選擇ES等更為適合的方式存儲
- 組合索引字段數(shù)不建議超過5個
解讀：如果5個字段還不能極大縮小row范圍淆游，八成是設計有問題
不建議在頻繁更新的字段上建立索引
非必要不要進行JOIN查詢傍睹，如果要進行JOIN查詢，被JOIN的字段必須類型相同犹菱，并建立索引
解讀：踩過因為JOIN字段類型不一致拾稳，而導致全表掃描的坑么？
- 理解組合索引最左前綴原則腊脱，避免重復建設索引访得，如果建立了(a,b,c)，相當于建立了(a), (a,b), (a,b,c)
六陕凹、SQL規(guī)范
- 禁止使用select *悍抑，只獲取必要字段
解讀：
- select *會增加cpu/io/內(nèi)存/帶寬的消耗
- 指定字段能有效利用索引覆蓋
- 指定字段查詢，在表結(jié)構(gòu)變更時捆姜，能保證對應用程序無影響
- insert必須指定字段传趾，禁止使用insert into T values()
解讀：指定字段插入，在表結(jié)構(gòu)變更時泥技，能保證對應用程序無影響
隱式類型轉(zhuǎn)換會使索引失效浆兰，導致全表掃描
禁止在where條件列使用函數(shù)或者表達式
解讀：導致不能命中索引磕仅，全表掃描
- 禁止負向查詢以及%開頭的模糊查詢
解讀：導致不能命中索引，全表掃描
禁止大表JOIN和子查詢
同一個字段上的OR必須改寫成IN簸呈，IN的值必須少于50個
應用程序必須捕獲SQL異常
解讀：方便定位線上問題
說明：本軍規(guī)適用于并發(fā)量大榕订，數(shù)據(jù)量大的典型互聯(lián)網(wǎng)業(yè)務，可直接帶走參考蜕便，不謝劫恒。
