一旦您的資料達到穩定大小，或成長中的資料表增加數十或數百 MB 時，請考慮使用 OPTIMIZE TABLE 陳述式來重新組織資料表並壓縮任何浪費的空間。重新組織的資料表需要較少的磁碟 I/O 來執行完整資料表掃描。這是一種簡單的技術，當其他技術（例如改善索引使用情況或調整應用程式碼）不切實際時，可以提高效能。

OPTIMIZE TABLE 會複製資料表的資料部分並重建索引。好處來自於索引內資料的改善封裝，以及資料表空間和磁碟內減少的碎片。好處因每個資料表中的資料而異。您可能會發現某些資料表有顯著的增益，而其他資料表則沒有，或者增益會隨著時間推移而減少，直到您下次最佳化資料表為止。如果資料表很大，或者重建的索引不適合緩衝池，則此操作可能會很慢。在向資料表新增大量資料後，第一次執行通常比之後的執行慢得多。

在 InnoDB 中，擁有一個較長的 PRIMARY KEY（可以是具有較長值的單一資料行，也可以是形成較長複合值的多個資料行）會浪費大量的磁碟空間。資料列的主鍵值會重複出現在所有指向同一資料列的次要索引記錄中。（請參閱第 17.6.2.1 節，「叢集索引和次要索引」。）如果您的主鍵較長，請建立 AUTO_INCREMENT 資料行作為主鍵，或者索引較長 VARCHAR 資料行的前綴，而不是整個資料行。

使用 VARCHAR 資料類型，而不是 CHAR 來儲存可變長度的字串或具有許多 NULL 值的資料行。CHAR(N) 資料行總是需要 N 個字元來儲存資料，即使字串較短或其值為 NULL。較小的資料表更適合緩衝池，並減少磁碟 I/O。

當使用 COMPACT 列格式 (預設的 InnoDB 格式) 和可變長度的字元集 (例如 utf8mb4 或 sjis) 時，CHAR(N) 欄位會佔用可變的空間大小，但仍至少會佔用 N 個位元組。

對於大型表格，或包含大量重複文字或數值資料的表格，請考慮使用 COMPRESSED 列格式。將資料帶入緩衝池或執行完整表格掃描所需的磁碟 I/O 較少。在做出永久決定之前，請測量使用 COMPRESSED 相較於 COMPACT 列格式可以達到的壓縮量。