一旦您的数据达到稳定大小，或者正在增长的表已经增长了数十或数百兆字节，请考虑使用 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 行格式来衡量可以实现的压缩量。