-
一旦您的数据达到稳定大小,或者一个增长的表增加了数十或数百兆字节,考虑使用
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
行格式可以实现的压缩程度。