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，或者执行一个全表扫描。