目錄

• • 表優化
  • • 數據類型的選擇
    • • 避免列的值為NULL
      • VARCHAR和CHAR
      • 日期和時間類型
    • 選擇標識符（主鍵）的類型
    • 錯誤的表結構
    • • 一張表中有太多列
      • 太多的關聯
    • 適當建立冗余數據
    • • 混用范式和反范式
      • 建立緩存表和匯總表
    • 參考

表優化

此文章用于記錄《高性能MySQL》一書的知識點。

數據類型的選擇

• 避免列的值為NULL

  查詢包含值為NULL的列，會使索引、索引統計和值比較更加復雜，如果計劃在列上建索引，就應該盡量避免索引列含有NULL值

• 在保證足夠的范圍內，選擇最小、最簡單的數據類型
  更小的數據類型占用更少的磁盤、內存和CPU緩存、處理也更快

• VARCHAR和CHAR

  • VARCHAR需要適用1或2兩個額外字節記錄字符串長度，適用于:
• 字符串列最大長度比平均長度大很多
• 列更新少，所以不用擔心碎片問題
• 使用了UTF-8等復雜字符集，每個字符用不同字節數存儲
• CHAR適用的場景
• 經常變更的數據，因為定長的CHAR不易產生碎片
• 非常短的列，CHAR不需要額外的字節，因此存儲空間更有效率

• 日期和時間類型

  • DATETIME 使用8字節，不能自動根據時區轉換
  • TIMESTAMP 使用4字節，值與時區有關，會自動轉換

  通常情況下應盡量使用TIMESTAMP，因為它的空間效率更高

選擇標識符（主鍵）的類型

在滿足足夠的范圍需求，并且預留未來增長空間的前提下，應選擇最小、最簡單的數據類型

• 整數通常是標識列最好的選擇，因為整數不僅快而且可以使用自增等特性
• 應避免使用字符串作為標識列
  • 原因：
• 字符串更消耗空間，同時比較時比數字類型慢
• 隨機的字符串如：MD5、SHA1或者UUID，插入新數據時會隨機地插入到索引的不同位置，導致頁分裂、磁盤隨機訪問。

錯誤的表結構

• 一張表中有太多列

  MySQL的存儲引擎需要在服務器層與存儲引擎層之間通過行緩沖格式拷貝數據，然后在服務器層將緩沖內容解碼成各個列。過多的列會導致上述過程轉換代價過高。

• 太多的關聯

  如果希望查詢執行快速且并發性好，單個查詢最好在12個表內做關聯。

適當建立冗余數據

• 混用范式和反范式

  范式化的表，更新更快，同時只有很少或沒有重復的數據，表更小，但是查詢時通常需要昂貴的關聯操作，可能導致部分索引失效，而反范式會增加冗余數據但可以減少或避免關聯操作。

• 建立緩存表和匯總表

  案例：統計某個表的總數時，可以通過
  SELECT COUNT(*) FROM table，但次操作需要掃描表中大部分數據，效率較低。可以通過建立匯總表來統計表中的數據數，并在每次插入數據時更新匯總表中的數據。

參考

《高性能的MySQL》

總結

以上是生活随笔為你收集整理的MySQL优化（一）：表结构优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。