8.5.1 优化 InnoDBtable 的存储布局
- 一旦数据达到稳定的大小,或者正在增长的 table 增加了数十或几百兆字节,请考虑使用
OPTIMIZE TABLE
语句重新组织 table 并压缩所有浪费的空间。重组后的 table 需要较少的磁盘 I/O 来执行全 table 扫描。这是一种直接的技术,可以在其他技术(如改善索引使用率或调整应用程序代码)不可行时提高性能。
OPTIMIZE TABLE
复制 table 的数据部分并重建索引。好处来自改进索引内数据的打包,并减少了 table 空间和磁盘内的碎片。好处因每个 table 中的数据而异。您可能会发现其中一些收益显着,而其他收益则不大,或者收益随着时间的流逝而减少,直到您下次优化 table 格为止。如果 table 很大或正在重建的索引不适合缓冲池,则此操作可能会很慢。向 table 中添加大量数据后的第一次运行通常比以后的运行要慢得多。
-
在
InnoDB
中,具有长PRIMARY KEY
(要么是具有长值的单列,要么是形成长复合值的几列)会浪费大量磁盘空间。在指向同一行的所有辅助索引 Logging,行的主键值均重复。 (请参见第 14.6.2.1 节“群集索引和二级索引”。)如果主键很长,则创建AUTO_INCREMENT
列作为主键,或者为VARCHAR
较长列的前缀而不是整个列构建索引。 -
使用VARCHAR数据类型而不是CHAR来存储可变长度的字符串或用于具有许多
NULL
值的列。 CHAR(N)列始终使用*N
*个字符来存储数据,即使字符串较短或其值为NULL
。较小的 table 更适合缓冲池并减少磁盘 I/O。
当使用COMPACT
行格式(默认的InnoDB
格式)和可变长度字符集(例如utf8
或sjis
)时,CHAR(N)列占据可变的空间量,但仍至少* N
*个字节。
- 对于大 table 或包含大量重复文本或数字数据的 table,请考虑使用
COMPRESSED
行格式。将数据带入缓冲池或执行全 table 扫描所需的磁盘 I/O 更少。在做出永久性决定之前,请测量使用COMPRESSED
与COMPACT
行格式可以实现的压缩量。