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

OPTIMIZE TABLE 复制表的 data 部分并重建索引。好处来自索引内数据的改进打包，以及表空间和磁盘内碎片的减少。好处会根据每个表中的数据而有所不同。你可能会发现有些表有显著的收益，而另一些则没有，或者收益会随着时间的推移而减少，直到你下次优化该表。如果表很大或要重建的索引不适合缓冲池，此操作可能会很慢。在向表中添加大量数据后第一次运行通常比以后的运行要慢得多。

在 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 行格式来衡量可以实现的压缩量。