MySQL 基礎篇
轉載:
基礎規範
必須使用 InnoDB 存儲引擎
解讀:支持事務、行級鎖、併發性能更好、CPU及內存緩存頁優化使得資源利用率更高。
表字符集默認使用 utf8,必要時候使用 utf8mb4
解讀:萬國碼,無需轉碼,無亂碼風險,節省空間,utf8mb4 是 utf8 的超集,有存儲4字節例如表情符號時,使用它。
數據表、數據字段必須加入中文註釋
禁止使用存儲過程、視圖、觸發器、Event
解讀:高併發大數據的互聯網業務,架構設計思路是“解放數據庫 CPU,將計算轉移到服務層”,併發量大的情況下,這些功能很可能將數據庫拖死,業務邏輯放到服務層具備更好的擴展性,能夠輕易實現“增機器就加性能”。數據庫擅長存儲與索引,CPU 計算還是上移吧。
禁止存儲大文件或者大照片
解讀:爲何要讓數據庫做它不擅長的事情?大文件和照片存儲在文件系統,數據庫裏存 URI 多好。
控制單表數據量,單表記錄控制在千萬級
平衡範式與冗餘,爲提高效率可以犧牲範式設計,冗餘數據
命名規範
只允許使用內網域名,而不是 ip 連接數據庫
線上環境、開發環境、測試環境數據庫內網域名遵循命名規範
業務名稱:xxx
線上環境:dj.xxx.db
開發環境:dj.xxx.rdb
測試環境:dj.xxx.tdb
從庫在名稱後加-s標識,備庫在名稱後加-ss標識
線上從庫:dj.xxx-s.db
線上備庫:dj.xxx-sss.db
庫名、表名、字段名:小寫,下劃線風格,不超過32個字符,必須見名知意,禁止拼音英文混用
表名 t_xxx,非唯一索引名 idx_xxx,唯一索引名 uniq_xxx
表設計規範
單實例表個數必須控制在2000個以內
單表分表個數必須控制在1024個以內
單表列數目必須小於30
表必須有主鍵,例如自增主鍵,推薦使用 UNSIGNED 整數爲主鍵
解讀:
- 主鍵遞增,數據行寫入可以提高插入性能,可以避免 page 分裂,減少表碎片,提升空間和內存的使用;
- 主鍵要選擇較短的數據類型,InnoDB 引擎普通索引都會保存主鍵的值,較短的數據類型可以有效的減少索引的磁盤空間,提高索引的緩存效率;
- 無主鍵的表刪除,在 row 模式的主從架構,會導致備庫夯住;
禁止使用外鍵,如果有外鍵完整性約束,需要應用程序控制
解讀:外鍵會導致表與表之間耦合,update 與 delete 操作都會涉及相關聯的表,十分影響 SQL 的性能,甚至會造成死鎖。高併發情況下容易造成數據庫性能,大數據高併發業務場景數據庫使用以性能優先。
建議將大字段,訪問頻度低的字段拆分到單獨的表中存儲,分離冷熱數據
字段設計規範
必須把字段定義爲 NOT NULL 並且提供默認值
解讀:
- nul l的列使索引/索引統計/值比較都更加複雜,對 MySQL 來說更難優化;
- null 這種類型 MySQL 內部需要進行特殊處理,增加數據庫處理記錄的複雜性;同等條件下,表中有較多空字段的時候,數據庫的處理性能會降低很多;
- null 值需要更多的存儲空,無論是表還是索引中每行中的 null 的列都需要額外的空間來標識;
- 對 null 的處理時候,只能採用 is null 或 is not null,而不能採用 =、in、<、<>、!=、not in 這些操作符號。如:where name != 'shenjian',如果存在 name 爲 null 值的記錄,查詢結果就不會包含 name 爲 null 值的記錄;
禁止使用 TEXT、BLOB 類型
解讀:會浪費更多的磁盤和內存空間,非必要的大量的大字段查詢會淘汰掉熱數據,導致內存命中率急劇降低,影響數據庫性能。
禁止使用小數存儲貨幣
解讀:使用整數吧,小數容易導致錢對不上。
必須使用 varchar(20) 存儲手機號
解讀:
- 涉及到區號或者國家代號,可能出現+-();
- varchar 可以支持模糊查詢,例如:like“138%”;
禁止使用 ENUM,可使用 TINYINT 代替
解讀:
- 增加新的 ENUM 值要做 DDL 操作;
- ENUM 的內部實際存儲就是整數;
用好數值類型
解讀:
- tinyint(1Byte):有符號(signed)範圍是-128到127,無符號(unsigned)範圍是0到255。
- smallint(2Byte):有符號(signed)範圍是-32768到32767,無符號(unsigned)範圍是0到65535。
- mediumint(3Byte):有符號(signed)範圍是-8388608到8388607,無符號(unsigned)範圍是0到16777215。
- int(4Byte):有符號(signed)範圍是-2147483648到2147483647,無符號(unsigned)範圍是0到4294967295
- bigint(8Byte):有符號(signed)範圍是-9223372036854775808到9223372036854775807,無符號(unsigned)範圍是0到18446744073709551615
使用 INT UNSIGNED 存儲 IPv4,不要用 char(15)
根據業務區分使用 char/varchar
解讀:
- 字段長度固定,或者長度近似的業務場景,適合使用 char,能夠減少碎片,查詢性能高;
- 字段長度相差較大,或者更新較少的業務場景,適合使用 varchar,能夠減少空間;
根據業務區分使用 datetime/timestamp
解讀:前者佔用5個字節,後者佔用4個字節,存儲年使用 YEAR,存儲日期使用 DATE,存儲時間使用 datetime
索引設計規範
單表索引建議控制在5個以內
解讀:
- 互聯網高併發業務,太多索引會影響寫性能;
- 生成執行計劃時,如果索引太多,會降低性能,並可能導致 MySQL 選擇不到最優索引;
- 異常複雜的查詢需求,可以選擇 ES 等更爲適合的方式存儲;
單索引字段數不允許超過5個
解讀:字段超過5個時,實際已經起不到有效過濾數據的作用了。
禁止在更新十分頻繁、區分度不高的屬性上建立索引
解讀:
- 更新會變更B+樹,更新頻繁的字段建立索引會大大降低數據庫性能;
- 【性別】這種區分度不大的屬性,建立索引是沒有什麼意義的,不能有效過濾數據,性能與全表掃描類似;
建立組合索引,必須把區分度高的字段放在前面
解讀:能夠更加有效的過濾數據。
非必要不要進行 JOIN 查詢,如果要進行 JOIN 查詢,被 JOIN 的字段必須類型相同,並建立索引
理解組合索引最左前綴原則,避免重複建設索引,如果建立了(a,b,c),相當於建立了(a), (a,b), (a,b,c)
SQL 使用規範
禁止使用 SELECT *,只獲取必要的字段,需要顯示說明列屬性
解讀:
- 讀取不需要的列會增加 CPU、IO、NET 消耗;
- 不能有效的利用覆蓋索引;
- 使用 SELECT * 容易在增加或者刪除字段後出現程序 BUG;
禁止使用 INSERT INTO t_xxx VALUES(xxx),必須顯示指定插入的列屬性
解讀:容易在增加或者刪除字段後出現程序BUG。
禁止使用屬性隱式轉換
解讀:SELECT uid FROM t_user WHERE phone=13812345678 會導致全表掃描,而不能命中 phone 索引。
禁止在 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')。
禁止負向查詢,以及%開頭的模糊查詢
解讀:
- 負向查詢條件:NOT、!=、<>、!<、!>、NOT IN、NOT LIKE 等,會導致全表掃描;
- %開頭的模糊查詢,會導致全表掃描;
禁止大表使用 JOIN 查詢,禁止大表使用子查詢
解讀:會產生臨時表,消耗較多內存與 CPU,極大影響數據庫性能。
禁止使用 OR 條件,必須改爲 IN 查詢或者 UNION 查詢,IN 的值必須少於50個
解讀:舊版本 MySQL 的 OR 查詢是不能命中索引的,即使能命中索引,爲何要讓數據庫耗費更多的 CPU 幫助實施查詢優化呢。
使用 union all 替代 union,union 有去重開銷
limit 高效分頁(可選)
解讀:limit 越大,效率越低,select id from t limit 10000, 10; 改爲 select id from t where id > 10000 limit 10;。
SQL where 條件的順序不一定需要按照索引的順序
解讀:比如一個聯合索引是 name, age,查詢的時候 where 條件可以寫成 age=10 and name='張三'。
應用程序必須捕獲 SQL 異常,並有相應處理