一旦您的資料達到穩定大小，或成長中的資料表增加了數十或數百 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 資料列格式達成的壓縮量。