Documentation Home
MySQL 8.3 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 40.8Mb
PDF (A4) - 40.9Mb
Man Pages (TGZ) - 294.0Kb
Man Pages (Zip) - 409.0Kb
Info (Gzip) - 4.0Mb
Info (Zip) - 4.0Mb
Excerpts from this Manual

MySQL 8.3 Reference Manual  /  ...  /  Optimizing Storage Layout for InnoDB Tables

10.5.1 InnoDB表的存储布局优化

  • 一旦您的数据达到稳定大小,或者一个增长的表增加了数十或数百兆字节,考虑使用 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 格式)和可变长度字符集,如 utf8mb4sjisCHAR(N) 列占用可变的空间,但至少占用 N 字节。

  • 对于大型表或包含大量重复文本或数字数据的表,考虑使用 COMPRESSED 行格式。这样可以减少将数据带入缓冲池或执行完整表扫描所需的磁盘I/O。在做出永久决定之前,测量使用 COMPRESSEDCOMPACT 行格式可以实现的压缩程度。