8.5.1 Optimizing Storage Layout for InnoDB Tables

8.5 Optimizing for InnoDB Table 优化InnoDB 表

8.5.1 Optimizing Storage Layout for InnoDB Tables
8.5.2 Optimizing InnoDB Transaction Management
8.5.3 Optimizing InnoDB Read-Only Transactions
8.5.4 Optimizing InnoDB Redo Logging
8.5.5 Bulk Data Loading for InnoDB Tables
8.5.6 Optimizing InnoDB Queries
8.5.7 Optimizing InnoDB DDL Operations
8.5.8 Optimizing InnoDB Disk I/O
8.5.9 Optimizing InnoDB Configuration Variables
8.5.10 Optimizing InnoDB for Systems with Many Tables

InnoDB 存储引擎,MySQL 客户典型使用在生产数据库,并发性和可靠性是重要的。

InnoDB 是默认的存储引擎在MySQL 5.6，这个章节解释优化对于InnoDB 表的优化操作

8.5.1优化InnoDB表的存储布局

一旦你的数据达到一个稳定的大小,或者越来越多的表以10M或者100M增长,

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

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

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

OPTIMIZE TABLE 复制表的数据部分,重建索引。

收益来自改善的索引内部数据的改进,降低了表空间和磁盘的碎片。

好处取决于每个表的数据,你可能会发现有显著的收益,

好处随着时间的推移而减少,直到你下次优化表。

这个操作可以是很慢的如果表是大的,或者如果索引被重建不被放入到buffer pool.

第一次运行在增加大量的数据到一个表通常是很慢的

在InnoDB，有一个很长的PRIMARY KEY(无论是一个长度的值的单独的列,或者多个列形成一个长的组合值)

浪费了大量的磁盘空间。 主键值在所有的secondary index 记录是重复的

(See Section 14.2.6, “InnoDB Table and Index Structures”.)

创建一个AUTO_INCREMENT 列作为一个primary key 如果你的主键是很长的,

或者索引一个长的VARCHAR列的一个前缀 代替整个列

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

一个CHAR(N) 列总是花费N个字符串来存储数据,即使如果字符串是很短的或者它的值是NULL的,

小的表更好的放入到buffer pool和降低disk I/O.

当使用COMPACT 行格式（默认是InnoDB 格式)和可变长度字符串设置,比如utf8 or sjis, CHAR(N) 列 占据

一个变量数量空间, 但是至少仍旧是N字节。

对于大表, 或者包含大量的重复文本或者数字数据, 考虑使用COMPRESSED row format.

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

在做一个永久性的决定前,确认压缩的量,你可以完成通过使用COMPRESSED versus COMPACT row format.