参考方法文档：

https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb.html

InnoDB是MySQL客户通常在可靠性和并发性非常重要的生产数据库中使用的存储引擎。 InnoDB是MySQL 5.7中的默认存储引擎。本节介绍如何优化InnoDB表的数据库操作。

8.5.1 为InnoDB表优化存储布局

• 一旦数据达到稳定的大小，或者增长的表增加了几十或几百兆字节，请考虑使用OPTIMIZE TABLE语句来重新组织表并压缩任何浪费的空间。 重新组织的表需要较少的磁盘I / O来执行全表扫描。 当其他技术（如改进索引使用或调整应用程序代码）不切实际时，这是一种直接技术，可以提高性能。

OPTIMIZE TABLE复制表的数据部分并重建索引。 好处来自改进索引内的数据打包，减少表空间内和磁盘上的碎片。 好处取决于每个表中的数据。 您可能会发现某些人有显着的收益，有些没有，或者收益会随着时间的推移而下降，直到您再次优化表。 如果表很大或者重建的索引没有fit到buffer pool，则此操作可能会很慢。 在向表中添加大量数据之后的第一次运行通常比之后的运行慢得多。

• 在InnoDB中，具有较长的PRIMARY KEY（具有较长值的单个列或形成较长复合值的多个列）浪费了大量的磁盘空间。 一行中的主键值在所有指向同一行的二级索引记录中都是重复的。 （请参见第14.8.2.1节“集群索引和二级索引”。）如果主键较长，则创建一个AUTO_INCREMENT列作为主键 或者索引长VARCHAR列的前缀而不是整列 。

• 使用VARCHAR数据类型而不是CHAR来存储可变长度字符串或具有多个NULL值的列。 即使字符串较短或其值为NULL，CHAR（N）列也总是需要N个字符来存储数据。 较小的表格适合缓冲池，减少磁盘I / O。

在使用COMPACT行格式（默认InnoDB格式）和可变长度字符集（如utf8或sjis）时，CHAR（N）列占用可变的空间量，但仍至少为N个字节。

• 对于大表或者包含大量重复性文本或数字数据的表，请考虑使用COMPRESSED行格式。 将数据带入缓冲池或执行全表扫描需要更少的磁盘I / O。 在作出永决定之前，请测量使用COMPRESSED与COMPACT行格式可以达到的压缩量。

8.5.2 优化InnoDB事务管理

要优化InnoDB事务处理，请在事务功能的性能开销和服务器的工作负载之间找到理想的平衡点。 例如，如果应用程序每秒提交数千次，则应用程序可能会遇到性能问题，如果每2-3小时提交一次应用程序，则可能会遇到不同的性能问题。

• 默认的MySQL设置AUTOCOMMIT=1会对繁忙的数据库服务器施加性能限制。 在可行的情况下，通过发出SET AUTOCOMMIT = 0或START TRANSACTION语句，并在进行所有更改之后跟随一个COMMIT语句，将几个相关的数据更改操作包装为单个事务。

--mysql 默认是自动提交的。

如果事务对数据库进行了修改，InnoDB必须在每次事务提交时将日志刷新到磁盘。 当每次更改之后都进行提交（与缺省自动提交设置一样）时，存储设备的I / O吞吐量将对每秒潜在操作的数量设置上限。

• 或者，对于只包含单个SELECT语句的事务，打开AUTOCOMMIT可帮助InnoDB识别只读事务并对其进行优化。 有关要求，请参见第8.5.3节“优化InnoDB只读事务”。
• 避免插入，更新或删除大量行后执行回滚。 如果一个大事务正在降低服务器性能，那么回滚可能会使问题变得更糟，可能需要几倍的时间来执行原始数据更改操作。 杀死数据库进程没有帮助，因为回滚在服务器启动时重新开始。

为了尽量减少发生此问题的机会：

• 增加缓冲池的大小，以便所有数据更改更改都可以被缓存而不是立即写入磁盘。
• 设置innodb_change_buffering=all（默认值），以便除了插入之外，还可以缓存更新和删除操作。
• 考虑在大数据更改操作期间定期发出COMMIT语句，可能会将单个删除或更新分为多个在较少数量的行上操作的语句。--批量提交

为了摆脱发生的失控回滚，增加缓冲池，以便回滚成为CPU绑定并快速运行，或者终止服务器并使用innodb_force_recovery = 3重新启动。

在默认设置是innodb_change_buffering = all情况下，这种问题很少发生，它允许更新和删除操作被缓存在内存中，使得它们在第一时间执行起来更快，而且如果需要还可以更快地回滚。 确保在使用许多插入，更新或删除来处理长时间运行事务的服务器上使用此参数设置。

• 如果发生崩溃时可以承受某些最新的已提交事务的丢失，则可以将innodb_flush_log_at_trx_commit参数设置为0. InnoDB尽可能每秒刷新一次日志，但是无法保证刷新。 另外，将innodb_support_xa的值设置为0，这将减少由于在磁盘数据和二进制日志上同步而导致的磁盘刷新次数。

注意：

innodb_support_xa已弃用，将在未来版本中删除。 从MySQL 5.7.10开始，InnoDB对XA事务中的两阶段提交的支持始终处于启用状态，并且不再允许禁用innodb_support_xa。

• 当行被修改或删除时，行和关联的undo日志不会立即被删除，甚至在事务提交之后立即被删除。 旧数据将保留，直到完成较早或同时开始的事务，以便这些事务可以访问修改或删除行的先前状态。 因此，长时间运行的事务会阻止InnoDB清除不同事务更改的数据。
• 当在长时间运行的事务中修改或删除行时，使用READ COMMITTED和REPEATABLE READ隔离级别的其他事务如果读取了相同的行，则必须做更多的工作来重新构建旧数据。

---oracle 中是使用undo CR 块来保证一致性读的。

• 当长时间运行的事务修改一个表时，对其他事务的查询不使用覆盖索引技术。 通常可以从辅助索引中检索所有结果列的查询，代替从表格数据中查找适当的值。

如果发现二级索引页面的PAGE_MAX_TRX_ID太新，或者二级索引中的记录被删除标记，则InnoDB可能需要使用聚簇索引来查找记录。

8.5.3 优化InnoDB只读事务

InnoDB可以避免与为已知为只读的事务设置事务ID（TRX_ID字段）相关联的开销。 只有可能执行写入操作或锁定读取的事务（如SELECT ... FOR UPDATE）才需要事务ID。 消除不必要的事务标识会减少每次查询或数据更改语句构造读取视图时查阅的内部数据结构的大小。

--DML 才会打开一个事务

目前，InnoDB在以下情况下检测只读事务：

• 该事务以START TRANSACTION READ ONLY语句开始。 在这种情况下，尝试对数据库（对于InnoDB，MyISAM或其他类型的表）进行更改会导致错误，事务将以只读状态继续：

ERROR 1792 (25006): Cannot execute statement in a READ ONLY transaction

您仍然可以在只读事务中更改特定于会话的临时表，或者为它们发出锁定查询，因为这些更改和锁对任何其他事务都是不可见的。

• 自动提交设置处于打开状态，这样事务被保证是单个语句，并且组成事务的单个语句是“非锁定”SELECT语句。 也就是说，不使用FOR UPDATE或LOCK IN SHARED MODE子句的SELECT。
• 事务是在没有READ ONLY选项的情况下启动的，但是没有更新或者显式锁定行的语句已经被执行。 在需要更新或显式锁定之前，事务处于只读模式。

因此，对于读取密集型应用程序（例如报告生成器），可以通过将其分组到START TRANSACTION READ ONLY和COMMIT中，或者在运行SELECT语句之前打开自动提交设置，或者简单地通过避免 任何数据更改语句散布在查询中（查询中不要执行DML，读写分离）。

注意：

具有自动提交，non-locking 和 read-only （AC-NL-RO）资格的事务不在特定内部InnoDB数据结构中，因此未在SHOW ENGINE INNODB STATUS输出中列出。

8.5.4 优化InnoDB Redo Logging

考虑以下关于优化重做日志的指导原则：

使您的重做日志文件大，甚至与缓冲池一样大。 当InnoDB将重做日志文件写满时，它必须将修改后的缓冲池内容写入磁盘的检查点。 小的重做日志文件导致许多不必要的磁盘写入。 虽然历史上重要的重做日志文件会导致冗长的恢复时间，但现在恢复速度更快，您可以放心地使用大型重做日志文件。

重做日志文件的大小和数量使用innodb_log_file_size和innodb_log_files_in_group配置选项进行配置。

考虑增加日志缓冲区的大小。 大型日志缓冲区允许大型事务运行，而无需在事务提交之前将日志写入磁盘。 因此，如果您有更新，插入或删除多行的事务（大事务），则使日志缓冲区更大可节省磁盘I / O。 日志缓冲区大小是使用innodb_log_buffer_size配置选项配置的。

---innodb_log_buffer_size 建议设置大一点，对大型查询可以得到性能提升

8.5.5 为InnoDB 表批量加载数据

• 将数据导入InnoDB时，请关闭自动提交模式，因为它会为每个插入操作执行日志刷新到磁盘。 要在导入操作期间禁用自动提交，请使用SET autocommit和COMMIT语句将其绕过：

SET autocommit=0;

... SQL import statements ...

COMMIT;

mysqldump选项--opt创建快速导入到InnoDB表中的转储文件，即使没有用SET autocommit和COMMIT语句包装它们。

• 如果您对secondary keys具有唯一性约束，则可以通过在导入会话期间临时关闭唯一性检查来加快表导入的速度：

SET unique_checks=0;

... SQL import statements ...

SET unique_checks=1;

对于大型表，这节省了大量的磁盘I / O，因为InnoDB可以使用其更改缓冲区来批量写入二级索引记录。 确保数据不包含重复的key。

• 如果您的表中有FOREIGN KEY约束，则可以通过在导入会话期间关闭外键检查来加速表导入：

SET foreign_key_checks=0;

... SQL import statements ...

SET foreign_key_checks=1;

对于大表，这可以节省大量的磁盘I / O。

• 如果您需要插入多行，请使用多行INSERT语法来减少客户端和服务器之间的通信开销：

INSERT INTO yourtable VALUES (1,2), (5,5), ...;

这个适用于插入任何表，而不仅仅是InnoDB表。

--批量插入，而不是一个个insert 插入。

• 当对具有自动增量列的表进行批量插入时，将innodb_autoinc_lock_mode设置为2而不是缺省值1。

• 执行批量插入时，以PRIMARY KEY顺序插入行速度更快。 InnoDB表使用聚集索引，这使得按照PRIMARY KEY的顺序使用数据相对较快。 以PRIMARY KEY顺序执行批量插入对于不完全fit缓冲池的表尤其重要。
• 将数据加载到InnoDB FULLTEXT索引时，为了获得最佳性能，请遵循以下步骤：
• 在创建表的时候定义一个类型为BIGINT UNSIGNED NOT NULL的列FTS_DOC_ID，其唯一索引名为FTS_DOC_ID_INDEX。 例如：

CREATE TABLE t1 (

FTS_DOC_ID BIGINT unsigned NOT NULL AUTO_INCREMENT,

title varchar(255) NOT NULL DEFAULT ”,

text mediumtext NOT NULL,

PRIMARY KEY (`FTS_DOC_ID`)

) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE UNIQUE INDEX FTS_DOC_ID_INDEX on t1(FTS_DOC_ID);

• 加载数据到表
• 数据加载后创建FULLTEXT索引。

注意：

在表创建时添加FTS_DOC_ID列时，请确保在更新FULLTEXT索引列时更新FTS_DOC_ID列，因为FTS_DOC_ID必须随每个INSERT或UPDATE单调递增。 如果您选择不在表创建时添加FTS_DOC_ID，并让InnoDB为您管理DOC ID，InnoDB将添加FTS_DOC_ID作为隐藏列，并进行下一个CREATE FULLTEXT INDEX调用。 但是，这种方法需要重建表格，这会影响性能。

8.5.6 优化 InnoDB 查询

要调整InnoDB表的查询，请在每个表上创建一组适当的索引。

• 由于每个InnoDB表都有一个主键（无论是否请求），请为每个表指定一组主键列，这些列用于最重要和时间关键的查询中。
• 不要在主键中指定太多或太长的列，因为这些列值在每个二级索引中都是重复的。 当一个索引包含不必要的数据时，I / O读取这个数据和内存来缓存它会降低服务器的性能和可伸缩性。
• 不要为每个列创建单独的二级索引，因为每个查询只能使用一个索引。 只有少数不同值的很少测试的列或列的索引可能对任何查询都没有帮助。 如果对同一个表有许多查询，则测试不同的列组合，尝试创建少量关联的索引，而不是大量的单列索引。 如果索引包含结果集所需的所有列（称为覆盖索引），则查询可能完全避免读取表数据。
• 如果索引列不能包含任何NULL值，则在创建表时将其声明为NOT NULL。 当知道每列是否包含NULL值时，优化器可以更好地确定哪个索引最有效地用于查询。
• 您可以优化InnoDB表的单一查询事务
• 如果您经常对不频繁更新的表进行循环查询，请启用查询缓存：

[mysqld]

query_cache_type = 1

query_cache_size = 10M

--这个有点像 oracle result cache的意思

8.5.7 优化 InnoDB DDL 操作

• 对于表和索引上的DDL操作（CREATE，ALTER和DROP语句） ，InnoDB表最重要的方面是在MySQL 5.5和更高版本中创建和删除二级索引比在早期版本中快得多。
• “快速索引创建”使得在某些情况下，在将数据加载到表中之前先删除索引，然后在加载数据后重新创建索引。
• 使用TRUNCATE TABLE来清空表，而不是DELETE FROM tbl_name。 外键约束可以使TRUNCATE语句像常规的DELETE语句一样工作，在这种情况下，像DROP TABLE和CREATE TABLE这样的命令序列可能是最快的。
• 由于主键是每个InnoDB表的存储布局不可或缺的组成部分，并且更改主键的定义涉及重新组织的一个表，因此始终将主键设置为CREATE TABLE语句的一部分，并提前计划，以便您之后不需要ALTER或DROP主键。

8.5.8 优化 InnoDB 磁盘I/O

如果您遵循SQL操作的数据库设计和调优技术的最佳实践，但由于繁重的磁盘I / O活动，您的数据库仍然很慢，请考虑这些磁盘I / O优化。 如果Unix顶级工具或Windows任务管理器显示工作负载的CPU使用百分比低于70％，那么您的工作负载可能是磁盘限制的。

• 增加缓冲池大小

当表数据缓存在InnoDB缓冲池中时，可以通过查询重复访问它，而不需要任何磁盘I / O。 用innodb_buffer_pool_size选项指定缓冲池的大小。 此内存区域非常重要，通常建议将innodb_buffer_pool_size配置为系统内存的50％到75％。

--这就是 oracle 的buffer cache

• 调整flush 方式

在GNU / Linux和Unix的某些版本中，使用Unix fsync（）调用（InnoDB默认使用）和类似方法将文件清理到磁盘的速度惊人地慢。 如果数据库写入性能出现问题，请使用设置为O_DSYNC的innodb_flush_method参数进行基准测试。

• InnoDB在Linux上使用异步I / O子系统（本地AIO）来执行数据文件页的预读和写请求。 此行为由innodb_use_native_aio配置选项控制，该选项默认启用。 使用本地AIO时，I / O调度程序的类型对I / O性能有更大的影响。 通常，建议使用noop和deadline I/O调度程序。 进行基准测试，以确定哪个I / O调度程序为您的工作负载和环境提供最佳结果

• 在x86_64体系结构（AMD Opteron）的Solaris 10上使用InnoDB存储引擎时，对InnoDB相关文件使用直接I / O，以避免InnoDB性能下降。 要为整个用于存储InnoDB相关文件的UFS文件系统使用直接I / O，请使用forcedirectio选项安装它; 请参阅mount_ufs（1M）。 （Solaris 10 / x86_64上的默认设置不使用此选项。）要将直接I / O仅应用于InnoDB文件操作而不是整个文件系统，请设置innodb_flush_method = O_DIRECT。 使用这个设置，InnoDB调用directio（）替代fcntl（）来输入/输出数据文件（而不是输入/输出来log文件）。

• 在Solaris 2.6或更高版本中使用raw来存储数据和日志文件

在任何Solaris 2.6或更高版本以及任何平台（sparc / x86 / x64 / amd64）上使用innodb_buffer_pool_size值较大的InnoDB存储引擎时，应在InnoDB数据文件和日志文件的原始设备或单独的 direct I/O UFS文件系统，使用前面所述的forcedirectio挂载选项。 （如果需要对日志文件进行 direct I/O，则必须使用安装选项而不是设置innodb_flush_method。）Veritas文件系统VxFS的用户应使用convosync = direct mount选项。

不要将其他MySQL数据文件（如MyISAM表格的数据文件）放在 direct I/O文件系统上。 可执行文件或库不能放在 direct I/O文件系统上。

• 考虑 non-rotational 存储

非循环存储通常为随机I/O操作提供更好的性能（SSD）; 旋转存储是为了顺序I/O操作。 在通过旋转和非旋转存储设备分发数据和日志文件时，请考虑主要在每个文件上执行的I/O操作的类型。

随机的面向I / O的文件通常包括file-per-table和一般表空间数据文件，undo表空间文件和临时表空间文件。 顺序I / O的文件包括InnoDB系统表空间文件（由于写入缓冲和更改缓冲）和日志文件（如二进制日志文件和重做日志文件）。

使用非循环存储时，请查看以下配置选项的设置：

• innodb_checksum_algorithm

crc32选项使用更快的校验和算法，推荐用于快速存储系统。

• innodb_flush_neighbors

该选项优化了旋转存储设备的I / O。 禁用它用于非旋转存储或混合旋转和非旋转存储。

• innodb_io_capacity

对于较低端的非旋转存储设备，默认设置200通常是足够的。 对于更高端的总线连接设备，考虑更高的设置，如1000。

• innodb_io_capacity_max

默认值2000适用于使用非旋转存储的工作负载。 对于高端，总线连接的非旋转存储设备，考虑更高的设置，如2500。

• innodb_log_compressed_pages

如果重做日志位于非循环存储中，请考虑禁用此选项以减少日志记录

---此参数确定是否记录压缩页面的一个日志

• innodb_log_file_size

如果重做日志位于非循环存储中，请配置此选项以最大化高速缓存和写入组合。

• innodb_page_size

考虑使用与磁盘的内部扇区大小相匹配的页面大小。 早期的SSD设备通常具有4k扇区大小。 一些较新的设备具有16k扇区大小。 InnoDB的默认页面大小是16k。 保持页面大小接近存储设备块大小可将重写到磁盘的未更改数据量减至最少。

• binlog_row_image

如果二进制日志位于非循环存储中，并且所有表都有主键，请考虑将此选项设置为最小以减少日志记录。

确保为您的操作系统启用TRIM支持。 它通常默认启用。

• 增加I/O容量以避免积压

如果由于InnoDB检查点操作导致吞吐量周期性下降，请考虑增加innodb_io_capacity配置选项的值。 更高的值会导致更频繁的刷新，避免可能导致吞吐量下降的工作积压。

• 如果flushing不落后，则I降低I/O capacity

如果系统不落后于InnoDB刷新操作，请考虑降低innodb_io_capacity配置选项的值。 通常情况下，您保持该选项的值尽可能低，但不能太低，以致导致吞吐量的周期性下降，如前面的项目符号所述。 在可以降低选项值的典型场景中，您可能会在SHOW ENGINE INNODB STATUS的输出中看到类似这样的组合：

• 历史list 长度低，低于几千
• 插入缓冲区合并接近插入的行。
• 修改缓冲池中的页面始终远低于缓冲池的innodb_max_dirty_pages_pct。 （在服务器没有进行批量插入的时候测量;在批量插入时修改的页面百分比显着增加，这是正常的。）
• 日志序列号 - 上一个检查点小于7/8或理想情况下小于InnoDB日志文件总大小的6/8。

• 将系统表空间文件存储在Fusion-io设备上

通过在支持原子写入的Fusion-io设备上存储系统表空间文件（“ibdata文件”），您可以利用与双写缓冲区相关的I / O优化。 在这种情况下，自动禁用双写缓冲（innodb_doublewrite），并将Fusion-io原子写入用于所有数据文件。 此功能仅在Fusion-io硬件上受支持，并且仅适用于Linux上的Fusion-io NVMFS。 要充分利用此功能，建议使用innodb_flush_method设置O_DIRECT。

注意：

由于双写缓冲区设置是全局性的，所以对于驻留在非Fusion-io硬件上的数据文件，也会禁用双写缓冲。

• 禁用压缩页面的日志记录

使用InnoDB表格压缩功能时，当对压缩数据进行更改时，重新压缩页面的image将写入重做日志。 此行为由innodb_log_compressed_pages控制，该行为默认情况下已启用，以防止在恢复过程中使用不同版本的zlib压缩算法时可能发生的损坏。 如果您确定zlib版本不会更改，请禁用innodb_log_compressed_pages以减少修改压缩数据的工作负载的重做日志生成。

--这个参数是可以禁用的，如果不进行版本变化的话。

8.5.9 优化 InnoDB 配置变量

因为InnoDB存储引擎会自动执行许多优化，所以许多性能调优任务都涉及监控，以确保数据库性能良好，并在性能下降时更改配置选项。

参考 Section 14.16, “InnoDB Integration with MySQL Performance Schema” 关于性能监控部分

您可以执行的主要配置步骤包括：

• 使InnoDB能够在包含它们的系统上使用高性能内存分配器（分配内存）。
• 控制InnoDB缓存更改数据的数据更改操作的类型，以避免频繁的小磁盘写入。 由于默认设置是缓冲所有类型的数据更改操作，因此只有在需要减少缓冲量时才更改此设置。
• 使用innodb_adaptive_hash_index选项打开和关闭自适应哈希索引功能。 有关更多信息，请参见第14.4.3节“自适应散列索引”。 您可能会在非正常活动期间更改此设置，然后将其恢复到原始设置。
• 如果上下文切换是瓶颈，那么对InnoDB处理的并发线程数设置限制。请参见第14.6.6节“为InnoDB配置线程并发”。
• 控制InnoDB对预读操作的预取量。当系统没有使用I / O容量时，更多的预读可以提高查询的性能。预读过多会导致重负载系统的性能周期性下降。请参见第14.6.3.5节“配置InnoDB缓冲池预取（预读）”。
• 如果您有一个高端I / O子系统未被默认值充分利用，则增加后台线程的读取或写入操作的数量。请参见第14.6.7节“配置背景InnoDB I / O线程数”。
• 控制InnoDB在后台执行多少I / O操作。请参见第14.6.9节“配置InnoDB主线程I / O速率”。如果您观察到性能的周期性下降，您可能会缩减此设置。
• 控制确定InnoDB何时执行某些类型的后台写入的算法。请参见第14.6.3.6节“配置InnoDB缓冲池刷新”。该算法适用于某些类型的工作负载，但不适用于其他类型的工作负载，因此如果观察到性能下降，可能会关闭此设置。
• 利用多核处理器及其缓存内存配置，最大限度地减少上下文切换的延迟。请参见第14.6.10节“配置自旋锁查询”。
• 防止表扫描等一次性操作干扰存储在InnoDB缓冲区缓存中的频繁访问的数据。请参见第14.6.3.4节“使缓冲池抗扫描”。
• 将日志文件调整到对于可靠性和崩溃恢复有意义的大小。 InnoDB日志文件通常保持很小，以避免崩溃后的长时间启动。在MySQL 5.5中引入的优化加快了崩溃恢复过程的某些步骤。特别是，由于内存管理的改进算法，扫描重做日志和应用重做日志的速度更快。如果为了避免很长的启动时间而将您的日志文件人为保留较小，现在可以考虑增加日志文件大小，以减少由于重做日志记录的回收而发生的I / O。
• 配置InnoDB缓冲池的实例的大小和数量，对于具有多千兆字节缓冲池的系统尤为重要。请参见第14.6.3.3节“配置多个缓冲池实例”。
• 增加并发事务的最大数量，极大地提高了最繁忙数据库的可扩展性。请参见第14.4.8节“撤消日志”。
• 将purge 操作（一种垃圾收集）移动到后台线程中。请参见第14.6.11节“Configuring InnoDB Purge Scheduling”。要有效测量此设置的结果，请首先调整其他I / O相关的和线程相关的配置设置。
• 减少InnoDB在并发线程之间进行的交换量，以便繁忙服务器上的SQL操作不会排队并形成“交通堵塞”。为innodb_thread_concurrency选项设置一个值，对于高性能的现代系统，最高可达约32。增加innodb_concurrency_tickets选项的值，通常为5000左右（默认为5000）。这些选项的组合限制了InnoDB在任何时候处理的线程数量，并且允许每个线程在被交换之前做大量的工作，以便等待线程的数量保持低，并且操作可以在没有过度的上下文切换的情况下完成。

8.5.10 为具有多个表的系统优化InnoDB

如果配置了非持久性优化器统计信息（非默认配置），则InnoDB会在启动后第一次访问表时计算表的索引基数值，而不是将这些值存储在表中。 在将数据分成许多表的系统上，这一步可能需要很长时间。 由于此开销仅适用于初始表打开操作，要“预热”表供以后使用，请在启动后立即通过发出诸如SELECT 1 FROM tbl_name LIMIT 1之类的语句来访问它。

优化器统计信息默认保存到磁盘，由innodb_stats_persistent配置选项启用。