8.5.1 Optimizing Storage Layout for InnoDB Tables InnoDB表的存储布局优化

一旦你的数据达到一个稳定的大小,或者一个成长的表几十几百兆的增加,

考虑使用OPTIMIZE TABLE 语句来重新组织表,压缩任何浪费掉的空间。

重组表需要更少的disk I/O 来执行全表扫描。

这是一个明确的技术可以改善性能当其他的技术比如改善索引使用或者调优应用代码是不实际的。

优化表拷贝表的数据和重建索引,好处是改善索引内部的数据,减少表空间内的碎片。

好处取决于每个表的数据。你可能会发现有些显著的收益, 或者说收益随着时间减少知道你下一次优化表。

这个操作可能会慢的,如果表是大的或者如果索引被重建没有放到buffer pool.

在增加大量数据后第一次运行通畅是更慢的相比后面的运行

在InnoDB，有一个很长的PRIMARY KEY(无论是一个具有长的值的列,或者几列形成一个长的符合价值) 浪费了大量的磁盘空间。

一条记录的主键值是复制到所有的第2个index 记录,指向同一个行。

创建一个auto_increment列作为主键，如果你的主键是长的。

使用VARCHAR 数据类型代替CHAR 来存储长度可变的字符串或者对于那些有很多NULL值的列。

一个CHAR(N) 列总是占据N个字符串来存储数据,尽管字符串是短的或者它的值是NULL.

小表适合放在缓冲池中,并减少磁盘I/O。

当使用紧凑的记录格式(InnoDB格式) ,长度可变的字符集,比如utf8 or sjis, CHAR(N) 列占据空间,但是仍旧至少N个字节。

对于大的表, 或者包含大量的重复文件或者数字数据, 考虑使用COMPRESSED 记录格式。

更少的disk I/O被需要来把数据放入buffer pool，或者执行一个全表扫描。