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

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

在InnoDB中，具有长PRIMARY KEY值（具有长值的单个列，或形成长复合值的多个列）会浪费大量磁盘空间。一行的主键值在指向同一行的所有二级索引记录中都是重复的。（请参阅第 14.6.2.1 节，“聚簇索引和二级索引”。）如果您的主键很长，则创建一个AUTO_INCREMENT列作为主键，或者索引一个长VARCHAR列的前缀而不是整个列。

使用VARCHAR数据类型而不是CHAR存储可变长度字符串或具有许多 NULL值的列。列 总是使用字符来存储数据，即使字符串较短或其值为 . 较小的表更适合缓冲池并减少磁盘 I/O。 CHAR(N)NNULL

当使用COMPACT行格式（默认InnoDB格式）和可变长度字符集（例如 utf8or sjis）时， 列占用的空间量可变，但至少仍为字节数。 CHAR(N)N

对于很大或包含大量重复文本或数字数据的表格，请考虑使用 COMPRESSED行格式。将数据放入缓冲池或执行全表扫描所需的磁盘 I/O 更少。COMPRESSED在做出永久性决定之前，请衡量使用与 COMPACT行格式 相比可以实现的压缩量 。