一旦数据达到稳定大小，或者一个增长的表增加了十几兆或数百兆字节，考虑使用 OPTIMIZE TABLE 语句来重组表并压缩任何浪费空间。重组后的表需要进行全表扫描时执行更少的磁盘 I/O。这是一个简单有效的技术，当其他技术如改进索引使用或调优应用程序代码不切实际时可以提高性能。

OPTIMIZE TABLE 复制了表的数据部分并重建了索引。好处来自于索引中数据的更佳打包以及磁盘和表空间中的碎片减少。好处取决于每个表的数据。你可能会发现对一些表有显著收益，而对其他则没有，或者随着时间的推移，收益逐渐降低，直到你下次优化表为止。这项操作对于大型表或需要重建的索引不适合放入缓冲池时会很慢。第一次在添加大量数据到表后运行通常比之后的运行要慢得多。

在 InnoDB 中，如果主键（无论是单列或多列）过长，会浪费大量磁盘空间。每一行的主键值都被复制到所有指向该行的次要索引记录中。（参见第 17.6.2.1 节，“聚簇和次要索引”。）如果你的主键很长，创建一个 AUTO_INCREMENT 列作为主键；或者对一个很长的 VARCHAR 列的前缀进行索引，而不是整个列。

使用 VARCHAR 数据类型而不是 CHAR 来存储可变长度字符串或用于含有许多 NULL 值的列。一个 CHAR(N) 列无论字符串长度如何，都会占用至少 N 个字符的空间，即使字符串短于 N 或其值为 NULL。较小的表更适合缓冲池，减少了磁盘 I/O。

使用 COMPACT 行格式（InnoDB 的默认格式）和可变长度字符集，如 utf8mb4 或 sjis，CHAR(N) 列占用空间的大小是可变的，但至少为 N 字节。

对于大表或包含大量重复文本或数字数据的表，考虑使用 COMPRESSED 行格式。需要进行全表扫描时执行的磁盘 I/O更少。在做出永久决定之前，使用 COMPRESSED 和 COMPACT 行格式之间测量压缩效果。