MySQL軍規

一,基礎規範

• 表存儲引擎必須使用InnoDB
• 表字符集默認使用utf8,必要時使用utf8mb4

解讀:

(1)通用,無亂碼風險,漢字3個字節,英文1個字節

(2)utf8mb4是uft8的超集,有存儲4字節例如表情符號時,使用它

• 禁止使用存儲過程,視圖,觸發器,Event

解讀:

(1)對數據庫性能影響較大,互聯網業務,能讓站點層和服務層乾的事情,不要交到數據庫層.

(2)調試,排錯,遷移都比較困難,擴展性較差.

• 禁止在數據庫中存儲大文件,例如照片,能夠將大文件存儲在對象存儲系統,數據庫中存儲路徑
• 禁止在線上環境作數據庫壓力測試
• 測試,開發,線上數據庫環境必須隔離

二 命名規範

• 庫名,表名,列名必須小寫,採用下劃線分割
• 庫名錶名列名必須見名知義,長度不能超過32個字符
• 庫備份以bak爲前綴,以時間爲後綴
• 從庫必須以-s爲後綴
• 備庫必須以-ss爲後綴

三 表設計規範

• 單實例表個數必須控制在2000之內
• 單表分表個數必須控制在1024之內
• 表必須有主鍵,推薦使用UNSIGNED整數爲主鍵

潛在坑 刪除沒有主鍵的表,若是是以row模式的主從架構,從庫會掛住

• 禁止使用外鍵,若是要保證數據的完整性,應當由應用程序來實現

解讀:外鍵使得表之間耦合性增長,影響update/delete等SQL性能,有可能形成死鎖,高併發狀況下 容易成爲數據庫瓶頸

• 建議將大字段,訪問頻率低的字段拆分到單獨的表存儲,分離冷熱數據

 四 列設計規範

根據業務區分使用tinyint/int/bigint,分別佔用1/4/8字節

根據業務區分使用char/varchar

解讀

1 字段長度固定,或者長度近似的業務場景,適合使用char,可以減小碎片,查詢性能高

2 字段長度相差較大,或者更新較少的業務場景,適合使用varchar,可以減小空間

根據業務區分使用datetime/timestamp

解讀

前者佔5個字節,後者佔4個字節,存儲年用year,存儲日期用date,存儲時間用datetime

必須把字段定義爲NOT NULL 並設默認值

解讀

NULL的列使用索引,索引統計,值更加複雜,MYSQL更難優化

NULL須要更多的存儲空間

NULL只能採用IS NULL 或者IS NOT NULL 而在 = / != /in / not in 有大坑

使用INT UNSIGNED 存儲IPv4  不使用char(15)

 使用varchar(20)存儲手機號 不使用整數

解讀

1 牽扯到國家代號,可能會出現 +/ - /() 例如+86

2 手機號不會進行數學運算

3 varchar能夠模糊查詢 例如like'138%'

使用tinyint替換ENUM

 解讀ENUM增長新值要進行DDL操做

 

[轉自微信公衆號" 架構師之路"]