MySQL在互聯網業務使用建議

1、基礎規範

• 表存儲引擎必須使用InnoDB

• 表字符集默認使用utf8，必要時候使用utf8mb4

解讀：

（1）通用，無亂碼風險，漢字3字節，英文1字節

（2）utf8mb4是utf8的超集，有存儲4字節例如表情符號時，使用它

 

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

  
  

解讀：

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

（2）調試，排錯，遷移都比較困難，擴展性較差

 

• 禁止在數據庫中存儲大文件，例如照片，能夠將大文件存儲在對象存儲系統，數據庫中存儲路徑

• 禁止在線上環境作數據庫壓力測試

• 測試，開發，線上數據庫環境必須隔離

 

2、命名規範

• 庫名，表名，列名必須用小寫，採用下劃線分隔

解讀：abc，Abc，ABC都是給本身埋坑

 

• 庫名，表名，列名必須見名知義，長度不要超過32字符

解讀：tmp，wushan誰TM知道這些庫是幹嗎的

 

• 庫備份必須以bak爲前綴，以日期爲後綴

• 從庫必須以-s爲後綴

• 備庫必須以-ss爲後綴

 

3、表設計規範

• 單實例表個數必須控制在2000個之內

• 單表分表個數必須控制在1024個之內

• 表必須有主鍵，推薦使用UNSIGNED整數爲主鍵

  注意事項：用不用unsigned能夠參考一下這個問題：https://www.cnblogs.com/blankqdb/archive/2012/11/03/blank_qdb.html

潛在坑：刪除無主鍵的表，若是是row模式的主從架構，從庫會掛住

 

• 禁止使用外鍵，若是要保證完整性，應由應用程式實現

  
  

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

 

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

 

4、列設計規範

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

• 根據業務區分使用char/varchar

  
  

解讀：

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

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

 

• 根據業務區分使用datetime/timestamp

  注意事項: 能夠參考這篇文章：https://blog.51cto.com/hanchaohan/1751447

解讀：前者佔用5個字節，後者佔用4個字節，存儲年使用YEAR，存儲日期使用DATE，存儲時間使用datetime

 

• 必須把字段定義爲NOT NULL並設默認值 ,能夠參考這個文章：

  https://blog.csdn.net/u010737354/article/details/53081830     

  https://www.cnblogs.com/balfish/p/7905100.html
  

解讀：

（1）NULL的列使用索引，索引統計，值都更加複雜，MySQL更難優化

（2）NULL須要更多的存儲空間

（3）NULL只能採用IS NULL或者IS NOT NULL，而在=/!=/in/not in時有大坑

 

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

解讀：

（1）若是用CHAR(15)來存儲,則須要15個字節(VARCHAR則須要16個字節)。將IP用無符號整數存儲,只須要4個字節,能節約空間。

（2）對於範圍查找效率更高

   SELECT * FROM test_han WHERE ip BETWEEN INET_ATON('192.168.0.0') AND INET_ATON('192.168.0.255');

（3）SELECT * FROM test_han WHERE ip = INET_ATON('192.168.0.0');

   SELECT INET_ATON('192.168.0.0');

   SELECT INET_NTOA(3232235520);

       能夠參考一下這篇文章:http://www.voidcn.com/article/p-dnqfznsx-mc.html

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

解讀：

（1）牽扯到國家代號，可能出現+/-/()等字符，例如+86

（2）手機號不會用來作數學運算

（3）varchar能夠模糊查詢，例如like ‘138%’

 

• 使用TINYINT來代替ENUM

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

 

5、索引規範

• 惟一索引使用uniq_[字段名]來命名

• 非惟一索引使用idx_[字段名]來命名

• 單張表索引數量建議控制在5個之內

  索引參考:http://www.javashuo.com/article/p-dngxxgcb-gn.html

解讀：

（1）互聯網高併發業務，太多索引會影響寫性能

（2）生成執行計劃時，若是索引太多，會下降性能，並可能致使MySQL選擇不到最優索引

（3）異常複雜的查詢需求，能夠選擇ES等更爲適合的方式存儲

 

• 組合索引字段數不建議超過5個

解讀：若是5個字段還不能極大縮小row範圍，八成是設計有問題

 

• 不建議在頻繁更新的字段上創建索引

• 非必要不要進行JOIN查詢，若是要進行JOIN查詢，被JOIN的字段必須類型相同，並創建索引

解讀：踩過由於JOIN字段類型不一致，而致使全表掃描的坑麼？

 

• 理解組合索引最左前綴原則，避免重複建設索引，若是創建了(a,b,c)，至關於創建了(a), (a,b), (a,b,c)

 

6、SQL規範

• 禁止使用select *，只獲取必要字段

解讀：

（1）select *會增長cpu/io/內存/帶寬的消耗

（2）指定字段能有效利用索引覆蓋

（3）指定字段查詢，在表結構變動時，能保證對應用程序無影響

 

• insert必須指定字段，禁止使用insert into T values()

解讀：指定字段插入，在表結構變動時，能保證對應用程序無影響

 

• 隱式類型轉換會使索引失效，致使全表掃描

 

• 禁止在where條件列使用函數或者表達式

解讀：致使不能命中索引，全表掃描

 

• 禁止負向查詢以及%開頭的模糊查詢

解讀：致使不能命中索引，全表掃描

 

• 禁止大表JOIN和子查詢

• 同一個字段上的OR必須改寫問IN，IN的值必須少於50個

• 應用程序必須捕獲SQL異常

解讀：方便定位線上問題

說明：上面建議用於併發量大，數據量大的典型互聯網業務