共計 2806 個字符，預計需要花費 8 分鐘才能閱讀完成。

這篇文章主要介紹“優化 | 重要的 MySQL 開發規范都在這了”，在日常操作中，相信很多人在優化 | 重要的 MySQL 開發規范都在這了問題上存在疑惑，丸趣 TV 小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”優化 | 重要的 MySQL 開發規范都在這了”的疑惑有所幫助！接下來，請跟著丸趣 TV 小編一起來學習吧！

1、默認使用 InnoDB 引擎
【老葉觀點】已多次呼吁過了，InnoDB 適用于幾乎 99% 的 MySQL 應用場景，而且在 MySQL 5.7 的系統表都改成 InnoDB 了，還有什么理由再死守 MyISAM 呢。

此外，頻繁讀寫的 InnoDB 表，一定要使用具有自增 / 順序特征的整型作為顯式主鍵。

2、字符集選擇 utf-8
【老葉觀點】若為了節省磁盤空間，則建議選擇 latin1。建議選擇 utf- 8 通常是為了所謂的“通用性”，但事實上用戶提交的 utf- 8 數據也一樣可以以 latin1 字符集存儲。

用 latin1 存儲 utf- 8 數據可能遇到的麻煩是，如果有基于中文的檢索時，可能無法 100% 準確（老葉親自簡單測試常規的中文完檢索全不是問題，也就是一般的中文對比是沒問題的）。

用 latin1 字符集存儲 utf- 8 數據的做法是：在 web 端 (用戶端) 的字符集是 utf-8，后端程序也采用 utf- 8 來處理，但 character_set_client、character_set_connection、character_set_results、character_set_database、character_set_server 這幾個都是 latin1，且數據表、字段的字符集也是 latin1。或者說數據表采用 latin1，每次連接后執行  SET NAMES LATIN1  即可。

3、InnoDB 表行記錄物理長度不超過 8KB

【老葉觀點】InnoDB 的 data page 默認是 16KB，基于 B +Tree 的特點，一個 data page 中需要至少存儲 2 條記錄。因此，當實際存儲長度超過 8KB（尤其是 TEXT/BLOB 列）的大列（large column）時會引起“page-overflow 存儲”，類似 ORACLE 中的“行遷移”。

因此，如果必須使用大列（尤其是 TEXT/BLOB 類型）且讀寫頻繁的話，則最好把這些列拆分到子表中，不要和主表放在一起存儲。如果不太頻繁，可以考慮繼續保留在主表中。

當然了，如果將 innodb_page_size 選項修改成 8KB，那么行記錄物理長度建議不超過 4KB。

【參考】：[MySQL 優化案例]系列 — 優化 InnoDB 表 BLOB 列的存儲效率。

4、是否使用分區表
【老葉觀點】在一些使用分區表后明顯可以提升性能或者運維便利性的場景下，還是建議使用分區表。

比如老葉就在 zabbix 的數據庫采用 TokuDB 引擎的前提下，又根據時間維度使用了分區表。這樣的好處是保證 zabbix 日常應用不受到影響前提下，方便管理員例行刪除過去數據，只需要刪除相應分區即可，不需再執行一個非常慢的 DELETE 而影響整體性能。

參考：遷移 Zabbix 數據庫到 TokuDB。

5、是否使用存儲過程、觸發器
【老葉觀點】在一些合適的場景下，用存儲過程、觸發器也完全沒問題。

我們以前就是利用存儲完成游戲業務邏輯處理，性能上不是問題，而且一旦需求有變更，只需修改存儲過程，變更代價很低。我們還利用觸發器維護一個頻繁更新的表，對這個表的所有變更都將部分字段同步更新到另一個表中（類似物化視圖的變相實現），也不存在性能問題。

不要把 MySQL 的存儲過程和觸發器視為洪水猛獸，用好的話，沒有問題的，真遇到問題了再優化也不遲。另外，MySQL 因為沒有物化視圖，因此視圖能不用就盡量少用吧。

6、選擇合適的類型
【老葉觀點】除了常見的建議外，還有其他幾個要點：

6.1、用 INT UNSIGNED 存儲 IPV4 地址，用 INET_ATON()、INET_NTOA()進行轉換，基本上沒必要使用 CHAR(15)來存儲。

6.2、枚舉類型可以使用 ENUM，ENUM 的內部存儲機制是采用 TINYINT 或 SMALLINT（并非 CHAR/VARCHAR），性能一點都不差，記住千萬別用 CHAR/VARCHAR 來存儲枚舉數據。

6.3、還個早前一直在傳播的“常識性誤導”，建議用 TIMESTAMP 取代 DATETIME。其實從 5.6 開始，建議優先選擇 DATETIME 存儲日期時間，因為它的可用范圍比 TIMESTAMP 更大，物理存儲上僅比 TIMESTAMP 多 1 個字節，整體性能上的損失并不大。

6.4、所有字段定義中，默認都加上 NOT NULL 約束，除非必須為 NULL（但我也想不出來什么場景下必須要在數據庫中存儲 NULL 值，可以用 0 來表示）。在對該字段進行 COUNT()統計時，統計結果更準確（值為 NULL 的不會被 COUNT 統計進去），或者執行 WHERE column IS NULL 檢索時，也可以快速返回結果。

6.5、盡可能不要直接 SELECT * 讀取全部字段，尤其是表中存在 TEXT/BLOB 大列的時候?？赡鼙緛聿恍枰x取這些列，但因為偷懶寫成 SELECT * 導致內存 buffer pool 被這些“垃圾”數據把真正需要緩沖起來的熱點數據給洗出去了。

8、關于索引
【老葉觀點】除了常見的建議外，還有幾個要點：

8.1、超過 20 個長度的字符串列，最好創建前綴索引而非整列索引（例如：ALTER TABLE t1 ADD INDEX(user(20))），可以有效提高索引利用率，不過它的缺點是對這個列排序時用不到前綴索引。前綴索引的長度可以基于對該字段的統計得出，一般略大于平均長度一點就可以了。

8.2、定期用 pt-duplicate-key-checker 工具檢查并刪除重復的索引。比如 index idx1(a, b) 索引已經涵蓋了 index idx2(a)，就可以刪除 idx2 索引了。

8.3、有多字段聯合索引時，WHERE 中過濾條件的字段順序無需和索引一致，但如果有排序、分組則就必須一致了。

比如有聯合索引 idx1(a, b, c)，那么下面的 SQL 都可以完整用到索引：

[MySQL FAQ]系列 — 從 MyISAM 轉到 InnoDB 需要注意什么

[MySQL FAQ]系列 — 為什么 InnoDB 表要建議用自增列做主鍵

小談 MySQL 字符集

[MySQL 優化案例]系列 — 優化 InnoDB 表 BLOB 列的存儲效率

遷移 Zabbix 數據庫到 TokuDB

[MySQL 優化案例]系列 — 分頁優化

[MySQL 優化案例]系列 — RAND()優化

[MySQL FAQ]系列 — 什么情況下會用到臨時表

[MySQL FAQ]系列 — EXPLAIN 結果中哪些信息要引起關注

到此，關于“優化 | 重要的 MySQL 開發規范都在這了”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注丸趣 TV 網站，丸趣 TV 小編會繼續努力為大家帶來更多實用的文章！