mysql5.7官网直译InnoDB表优化--只读事物优化，Redo日志优化，数据加载优化，innoDB查询优化，DDL操作优化

8.5.3 Optimizing InnoDB Read-Only Transactions 只读事物的优化
InnoDB能够避免对一个只读事物设置事物ID(TRX_ID属性)的相关开销。一个事物ID只有在写事物或者是锁读例如SELECT .... FOR UPDATE时才需要。排除不需要的事物id减少了内部数据结构的大小,该数据结构在每次查询中都用到或者是在数据改变语句中构造一个读试图。
InnoDB发觉一个只读事物当如下情况：
>事物是以START TRANSACTION READ ONLY语句开头。在这种情况下，试着改变数据库(对于InnoDB,MyISAM，或者其他类型的表)会引发一个错误，并且事物继续在只读的状态下：
ERROR 1792 (25006): Cannot execute statement in a READ ONLY transaction.在只读事物里不能执行语句
你能够改变session状态在一个临时表当时只读事物时，或者是关于他们的锁查询问题，因为这些改变和锁对其他事物不可见。
>autocommit设置打开，所以事物一定是一个简单语句，并且简单语句是一个没有锁的查询语句事物。也就是，一个select没有使用FOR UPDATE或者LOCK IN SHARED MODE条件。
>事物开始没有READ ONLY选项，但是没有更新或者是明显带有行锁的语句被执行。直到更新或者是明显的锁被要求，要不事物一直处于read-only模式。
这样，对于一个多读应用比方说报告生成器，你能调整一系列InnoDB查询通过分组在STARTTRANSACTION_READ_ONLY和COMMIT,或者打开自动提交设置在运行SELECT语句之前，或者简单来说不要让任何更新语句来打散查询。
具体信息关于START_TRANSACTION和autocommit.请看13.3.1的START TRANSACTION,COMMIT,and ROLLBACK Syntax"。开始事物，提交和回滚的语法。
-------------------------------------
8.5.4 Optimizing InnoDB Redo Logging 优化InnoDB Redo日志
考虑如下的优化指导：
>使得你的redo日志文件变大，甚至和缓存池一样大。当InnoDB写满了redo日志文件，它必须在一个检查点上将在缓存中修改的内容写入磁盘。小的redo日志文件会使得不必要的磁盘写。虽然大的redo日志文件会使得恢复时间变长，现在恢复非常快所以你能够考虑使用大的redo日志文件。
redo日志文件的大小和数量被配置通过使用innodb_log_file_size和innodb_log_files_in_group配置选项。更多信息关于修改已经存在的redo日志文件的配置，请看14.7.2的改变InnoDB redo日志文件的数量或者大小。
>考虑增加log缓存的大小。一个大的日志缓存能够保证大事物的运行而不需要再事物提交之前写日志到磁盘。这样，如果你有事物关于更新，插入或者删除多行数据，使得日志缓存变大可以节省磁盘I/O.日志缓存大小可以通过使用innodb_log_buffer_size配置选项来配置。
--------------------------------------
8.5.5 Bulk Data Loading for InnoDB Tables InnoDB表中数据块的加载
这些优化建议是对8.4.2.1的插入语句优化的补充使得插入添加更快。
>当导入数据到InnoDB,关闭自动提交模式，因为他会对每一次插入都做一次日志刷新到磁盘。为了使得导入数据不使用自动提交，在它周围包裹上set autocommit和commit语句：
SET autocommit=0;
... SQL import statements ...
COMMIT;
mysqldump 选项--opt创建了dump文件，能够快速导入数据到InnoDB表中，即使没有对它们添加SET AUTOCOMMIT和commit语句。
>如果你在二级索引上添加了唯一限制，你能够临时关闭唯一性检查在一个导入任务中从而快速完成导入表数据：
SET unique_checks=0;
... SQL import statements ...
SET unique_checks=1;
对于一张大表来说，这能够减少许多磁盘I/O
>如果你需要插入多行，通过使用多行插入语法来减少客户端和服务器端的通信开销：
INSERT INTO yourtable VALUES (1,2), (5,5), ...;
这个建议可以用于任何表，而不仅仅是InnoDB表。
>当大量插入表数据通过自动增长的列，设置innodb_autoinc_lock_mode 为2而不是默认值1.具体请看14.8.1.5的AUTO_INCREMENT 处理在InnoDB中的详情。
>当大量插入，根据主键顺序插入会更快。InnoDB表使用一个聚簇索引，使得可以通过主键顺序快速的使用数据。根据主键顺序大量插入特别重要对于不能完整放入缓存池的表来说。
>当加载数据到一个InnoDB FUllTEXT索引的优化，按下面的步骤完成：
 a,在表创建时定义一个列FTS_DOC_ID,其类型为BIGINT UNSIGNED NOT NULL,使用唯一索引名字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=utf8;
CREATE UNIQUE INDEX FTS_DOC_ID_INDEX on t1(FTS_DOC_ID);
b,加载数据到表中。
c,在数据加载后创建FULLTEXT索引。
  注意：
  当在表创建是增加了FTS_DOC_ID列，必须保证FTS_DOC_ID列在FULLTEXT索引列更新的时候也同样被更新，所以必须对FTS_DOC_ID增加对每一个插入或者更新的监听。如果你选择不在创建的时候增加列FTS_DOC_ID，那么InnoDB会替你管理DOC IDs,InnoDB 会暗中添加FTS_DOC_ID通过在CREATE FULLTEXT INDEX调用的时候自动添加并隐藏不显示。然后这种方式需要重构表会影响性能。
-----------------------------------
8.5.6 Optimizing InnoDB Queries 优化InnoDB查询
为了协调对InnoDB表的查询，在每一个表中创建一个合适的索引集合。具体看8.3.1中的怎么样在MYSql中使用索引的详细信息。
下面这些是对InnoDB索引的指导：
>因为每张innoDB表都有一个主键(不管你是否需要)，特别是对于多个列组成主键的表，这些列被使用在最重要的查询和有严格时间要求的查询中。
>不要设置特别藏或者是特别多的列在主键上，因为这些列的值会在每一个二级索引中存储。当一个索引包含了不必要的数据，I/O读取这些数据然后缓存存储这些减少了数据库性能和可用性。
>不要在每一个列上都创建一个独立的二级索引，因为每一个查询只能使用一个索引。如果索引中的列很少被查询或者列中只有少量的值不同，那么索引对任何查询都基本没啥作用。如果你有多个查询在同一张表，测试不同的列组合，试着创建一个有联系的列的结合索引，而不是创建一堆的单一列索引。如果一个索引包含了查询要的所有的结果数据，那么查询可以完全不去读取表中的数据。
>如果一个被索引的列不能包含任何NULL值，那么当你在创建表时声明它为NOT NULL。优化器能够更好的决定哪一个索引最有效在当前的查询中使用，当它知道是否每一个列可能会是NULL值的情况下。
>你能优化单一查询事物在InnoDB表，使用8.5.3的优化只读事物的技术。
----------------------------------
8.5.7 Optimizing InnoDB DDL Operations InnoDB DDL 操作的优化
>对于表的DDL操作和索引(CREATE,ALTER,和DROP语句)，对于InnoDB表最重要的放面是快速的创建和删除二级索引在mysql5.5和更高版本，和早些版本相比。具体看14.13.1的在线DDL试图详情。
>“快速创建索引”使得它需要在某些情况下在加载数据到表之前先快速删除索引，然后再加载数据之后重建索引。
>使用TRUNCATE TABLE来清空一张表，而不是用DELETE FROM tb1_name。外键限制能够使得一个TRUNCATE语句像一个规律的DELETE语句，在这种情况下一系列的命令例如DROP TABLE和CREATE TABLE也许会更快。
>因为主键是每一个InnoDB表存储布局中的一个组成部分，并且改变主键的定义会涉及到整个表的重构，所以总是在创建表时涉及主键部分，并且提前规划从而保证在创建之后不需要再次修改或者删除。