優化 InnoDB 表的儲存佈局

1. 在 InnoDB 中，具有長 PRIMARY KEY（具有冗長值的單個列或者形成長複合值的多個列）浪費了大量磁碟空間。在指向同一行的所有輔助索引記錄中，行的主鍵值重複。如果主鍵很長，則建立一個 AUTO_INCREMENT 列作為主鍵。
2. 使用 VARCHAR 資料型別而不是 CHAR 來儲存可變長度字串或具有許多 NULL 值的列。即使字串較短或其值為 NULL，CHAR(N) 列也始終使用 N 個字元來儲存資料。較小的表更適合緩衝池並減少磁碟 I / O.

當使用 COMPACT 行格式（預設的 InnoDB 格式）和可變長度字符集（如 utf8 或 sjis）時，CHAR(N) 列佔用可變的空間量，但仍至少佔用 N 個位元組。

3. 對於大型表或包含大量重複文字或數字資料的表，請考慮使用 COMPRESSED 行格式。將資料放入緩衝池或執行全表掃描需要較少的磁碟 I / O. 在做出永久性決策之前，請使用 COMPRESSED 與 COMPACT 行格式測量可以實現的壓縮量。警告： 基準測試很少顯示比 2：1 壓縮更好，並且緩衝區中有很多開銷用於 COMPRESSED。
4. 一旦資料達到穩定大小，或者增長的表增加了幾十或幾百兆位元組，請考慮使用 OPTIMIZE TABLE 語句重新組織表並壓縮任何浪費的空間。重組的表需要較少的磁碟 I / O 來執行全表掃描。這是一種簡單的技術，可以在其他技術（如改進索引使用或調整應用程式程式碼）不切實際時提高效能。警告 ：無論表大小如何，OPTIMIZE TABLE 都應該很少執行。這是因為它的成本很高，並且很少能夠提高表格的價值。InnoDB 相當擅長保持其 B +樹免於浪費大量空間。

OPTIMIZE TABLE 複製表的資料部分並重建索引。其好處來自於改進了索引中資料的打包，減少了表空間和磁碟上的碎片。好處取決於每個表中的資料。你可能會發現某些人而不是其他人獲得了顯著的收益，或者在你下次優化表之前，收益會隨著時間的推移而降低。如果表很大或者正在重建的索引不適合緩衝池，則此操作可能會很慢。向表中新增大量資料後的第一次執行通常比以後的執行慢得多。