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