(root@(none)) Mysql >show variables like 'version%';
+-------------------------+------------------------------+
| Variable_name | Value |
+-------------------------+------------------------------+
| version | 5.7.16-log |
| version_comment | MySQL Community Server (GPL) |
| version_compile_machine | x86_64 |
| version_compile_os | linux-glibc2.5 |
+-------------------------+------------------------------+
4 rows in set (0.00 sec)
(root@(none)) Mysql >show variables like 'innodb_%';
+------------------------------------------+-----------------------------------------------------------------------------------------------
| Variable_name | Value
+------------------------------------------+-----------------------------------------------------------------------------------------------
| innodb_adaptive_flushing | ON
#innodb_io_capacity, innodb_max_dirty_pages_pct,innodb_adaptive_flushing这三个参数是为了解决SSD等大容量存储设备的出现而导致innoDB不能很好利用这类设备性能的困境而出现的，本文会结合mysql-5.5.34的源代码进行这三个参数的介绍。
#指定是否要根据负荷动态地调整InnoDB缓冲池中的刷新垃圾页面率。动态地调整垃圾页面率是为了避免突发的I/O并发量。该设置默认为启用。
| innodb_adaptive_flushing_lwm | 10
# 当自适应刷新功能开启时，低水位线表示重做日志的能力的百分比。
#该值表示redo log的一个最低容量限制百分比，默认为10，当没有达到这个值时，则不会page cleaner线程不会根据redo来判断是否刷页，细节见函数af_get_pct_for_lsn
| innodb_adaptive_hash_index | ON
#无论InnoDB adaptive hash index是启用还是关闭，需要根据负荷来判断，通过动态地开关 adaptive hash indexing来提高查询功能。由于adaptive hash index不是对所有的负荷都起作用，需根据实际的负荷来控制它启动和关闭的基准。详情请见14.2.13.6, “Adaptive Hash Indexes”。
该设置默认为启用。只需通过修改GLOBAL配置项来修改，不需要重启服务器。修改改配置需有超级权限。你也可以在服务器通过--skip-innodb_adaptive_hash_index来关闭该功能。
关闭the adaptive hash index，散列表将被立即清空。虽然散列表被清空但正常的操作仍然能继续。之前通过散列表执行的查询而现在将通过B-trees索引查询。当the adaptive hash index重启时，普通操作时将再次使用散列表。
S| innodb_adaptive_hash_index_parts | 8
| innodb_adaptive_max_sleep_delay | 150000
#允许InnoDB根据现有负荷自动调整 innodb_thread_sleep_delay值的大小。任何一个非零的值都允许自动使能，动态的调整 innodb_thread_sleep_delay的值，最高值可达 innodb_thread_sleep_delay配置的最大值。在大于16线程并发的InnoDB这样繁忙的系统中，这一配置项很有作用。（在实践中，有数百或成千上万的并发连接MySQL系统，它是最有价值的）
| innodb_api_bk_commit_interval | 5
# 在短时间内，多久通过InnoDB memcached 界面自动提交空闲连接。（5.6.17引入）
| innodb_api_disable_rowlock | OFF
#当innodb 分页式缓存执行DML操作的时候，使用这个变量去禁用行级锁。默认情况下innodb_api_disable_rowlocky设置为off, 这意味着分页式缓存请求获取和设置操作的行锁。当innodb_api_disable_rowlock 设置为on ，分页式缓存请求表锁而来代替行锁。
Innodb_api_disable_rowlock选项不是动态，它必须指定在mydqld命令行或MYSQL配置文件设置。插件安装后配置才会有效，在配置该参数需要重启数据库服务生效。
| innodb_api_enable_binlog | OFF
#允许您使用innodb memcached插件和mysql binary log
#Lets you use the InnoDB memcached plugin with the MySQL binary log. See Section 14.18,“InnoDB Integration with memcached” forusage details for this option.
#https://dev.mysql.com/doc/refman/5.6/en/innodb-memcached.html
| innodb_api_enable_mdl | OFF
#锁表被用于InnoDB分布式缓存插件中。因此可以在SQL接口被DDL去掉和修改。
| innodb_api_trx_level | 0
# 允许在分布式缓存接口处理中控制独立事务处理等级。细节请参看Section 14.18, “InnoDB Integration with memcached
一些数值的含义为：
§ 0 = READ UNCOMMITTED
§ 1 = READ COMMITTED
§ 2 = REPEATABLE READ
§ 3 = SERIALIZABLE
| innodb_autoextend_increment | 64
#当内存空间满时，增量空间被用来扩展InnoDB system tablespace，在MySQL5.6.6, 8之前默认值为64(M)，如果你设置innodb_file_per_table=1。
这个变量将不会在你创建的tablespace 文件里生效。这此文件是自动扩展的，不会参照innodb_autoextend_increment 值。初始化的扩展非常小，当扩展发生时增至4MB。
| innodb_autoinc_lock_mode | 1
# 此方式为innodb在插入自增字段时用到的锁定方式, 有三种模式，traditional(5.1 before),consecutive(5.1 begin default),interleaved,
# consecutive 是最安全，其他两种类型往往获得更好性能。
# 结论：innodb_autoinc_lock_mode为0时的，也就是官方说的traditional级别，该自增锁是表锁级别，且必须等待当前SQL执行完成后或者回滚掉才会释放，这样在高并发的情况下可想而知自增锁竞争是比较大的。
# 结论：innodb_autoinc_lock_mode为1时的，也就是官方说的consecutive级别，这时如果是单一的insert SQL，可以立即获得该锁，并立即释放，而不必等待当前SQL执行完成（除非在其他事务中已经有session获取了自增锁）。另外当SQL是一些批量insert sql时，比如insert into ...select ...,load data,replace ..select..时，这时还是表级锁，可以理解成退化为必须等待当前SQL执行完才释放。
可以认为，该值为1时是相对比较轻量的锁，也不会对复制产生影响，唯一的缺陷是产生的自增值不一定是完全连续的（不过个人认为这个往往不是很重要，也没必要根据自增id值来统计行数之类）。
# 结论：当innodb_autoinc_lock_mode设置为2时，所有insert种类的SQL都可以立马获得锁并释放，这时的效率最高。但是会引入一个新的问题：当binlog_format为statement时，这时的复制没法保证安全，因为批量的insert，比如insert ..select..语句在这个情况下，也可以立马获取到一大批的自增id值，不必锁整个表，slave在回放这个sql时必然会产生错乱。
但是反应到从库时，因为是基于statement的复制，必然出现主键冲突。
总结：1 innodb row复制时，可将innodb_autoinc_lock_mode设置为2，这时可在所有insert情况下表获得最大并发度
2 innodb statement复制时，可将innodb_autoinc_lock_mode设置为1，保证复制安全的同时，获得简单insert语句的最大并发度
3 myisam引擎情况下，无论什么样自增id锁都是表级锁，设置innodb_autoinc_lock_mode参数无效。
4 实际上提问者说到的在innodb引擎下自增id值作为主键的情况下，相比uuid或者自定义的主键，是可以提到插入速度的，因为innodb是主键聚集索引，实际的主键值必须按照主键顺序存取，那么自增id本身就是升序的，那么在插入数据时，底层就不必再做额外的排序操作，也减少了索引页分裂的次数，从而大大增加insert速度（除非其他方案也能保证主键完全自增）。
| innodb_buffer_pool_chunk_size | 134217728
#(5.7 引入)，MySQL 5.7.5后Innodb_buffer_pool_size一方面可以动态分配。但另一方面也引入了一个新特性，Innodb_buffer_pool_size分配必须是innodb_buffer_pool_chunk_size的倍数。同时最好是：innodb_buffer_pool_chunk_size*innodb_buffer_pool_instances.
默认为128M
| innodb_buffer_pool_dump_at_shutdown | ON
#解释：在关闭时把热数据dump到本地磁盘。
| innodb_buffer_pool_dump_now | OFF
#解释：采用手工方式把热数据dump到本地磁盘。
| innodb_buffer_pool_dump_pct | 40
#mysql5.7开始默认在数据库服务启动，停止时，预热与dump数据,设置dump的百分比，这部分数据是最热的数据.
#表示转储每个bp instance LRU上最热的page的百分比。通过设置该参数可以减少转储的page数。
| innodb_buffer_pool_filename | ib_buffer_pool
# 如果开启InnoDB预热功能，停止MySQL服务时，MySQL将InnoDB缓冲池中的热数据保存到数据库根目录中，默认文件名为ib_buffer_pool.
| innodb_buffer_pool_instances | 1
#innodb_buffer_pool_instances可以开启多个内存缓冲池，把需要缓冲的数据hash到不同的缓冲池中，这样可以并行的内存读写.
为了更好的并发性能，通过指定innodb_buffer_pool_instances（该值取值范围为1-64）创建多个缓存池，每个缓存池的大小为
innodb_buffer_pool_size/innodb_buffer_pool_instances，通常需要保持当个缓存池的大小大于1GB。
| innodb_buffer_pool_load_abort | OFF
#默认为关闭OFF。如果开启该参数，即便开启InnoDB预热功能，启动MySQL服务室，MySQL也不会将本地硬盘的热数据加载到InnoDB缓冲池中。
| innodb_buffer_pool_load_at_startup | ON
#解释：在启动时把热数据加载到内存。
| innodb_buffer_pool_load_now | OFF
#解释：采用手工方式把热数据加载到内存。
| innodb_buffer_pool_size | 536870912
# 调整innodb_buffer_pool_size大小，如果是单实例且绝大多数是InnoDB引擎表的话，可考虑设置为物理内存的50% ~ 75%左右；
#缓存数据块和索引块，对InnoDB表性能影响最大。通过查询show status like 'Innodb_buffer_pool_read%'，保证 (Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests越高越好.
#假设是一台单独给 MySQL 使用的主机，物理内存总大小为 8G，MySQL 最大连接数为 500，同时还使用 了 MyISAM 存储引擎，这时候我们的整体内存该如何分配呢？
内存分配为如下几大部分：
a) 系统使用，假设预留 800M；
b) 线程独享，约 2GB = 500 * (1MB + 1MB + 1MB + 512KB + 512KB)，组成大概如下:sort_buffer_size：1MB join_buffer_size：1MB read_buffer_size：1MB read_rnd_buffer_size：512KB thread_statck：512KB
c) MyISAM Key Cache，假设大概为 1.5GB；
d) Innodb Buffer Pool 最大可用量：8GB - 800MB - 2GB - 1.5GB = 3.7GB；
假设这个时候我们还按照 50%～80%的建议来设置，最小也是 4GB，而通过上面的估算，最大可用值 在 3.7GB 左右，那么很可能在系统负载很高当线程独享内存差不多出现极限情况的时候，系统很可能就 会出现内存不足的问题了
| innodb_change_buffer_max_size | 25
# 如果是日值类服务，可以考虑把这个增值调到 50
| innodb_change_buffering | all
#默认即可
#5.5之前。这还不叫change buffer，而是insert buffer；
#当更新/插入的非聚集索引的数据所对应的页不在内存中时（对非聚集索引的更新操作通常会带来随机IO），会将其放到一个insert buffer中，当随后页面被读到内存中时，会将这些变化的记录merge到页中。当服务器比较空闲时，后台线程也会做merge操作
但insert buffer会占用buffer pool，并且在非聚集索引很少时，并不总是必要的，反而会降低buffer pool做data cache的能力，
根据官方文档的描述，主要包括以下几个值：
1.all
The default value: buffer inserts, delete-marking operations, and purges.
2.none
Do not buffer any operations.
3.inserts
Buffer insert operations.
4.deletes
Buffer delete-marking operations.（包括delete和update操作）
5.changes
Buffer both inserts and delete-marking.
6.purges
Buffer the physical deletion operations that happen in the background
| innodb_checksum_algorithm | crc32
#Innodb引入了新的checksum计算方式，checksum算法由新参数 innodb_checksum_algorithm来控制，默认为crc32算法，主要有两种算法，一种是老的计算方法(innodb_checksum_algorithm=innodb)，使用这种算法是兼容老版本的MySQL。
因为使用了不同的算法计算checksum，会导致校验page失败。
| innodb_checksums | ON
#InnoDB在所有对磁盘的页面读取上使用校验和验证以确保额外容错防止硬件损坏或数据文件
| innodb_cmp_per_index_enabled | OFF
##表示是否统计每个表的每个索引的压缩状态，如果打开，信息会进行收集，并显示在information_schema的INNODB_CMP_PER_INDEX/INNODB_CMP_PER_INDEX_RESET中，这会有一定的性能损耗 .
| innodb_commit_concurrency | 0
#如你所见innodb_commit_concurrency仅用来保护行访问，使用内部结构和锁定分阶段提交，他仍是为保护变量。他限制innodb内核激活线程的commit。一个最佳的值也依赖很多其他因素。但是从5.1.36开始mysql不允许将该值设置为非0，该值只能为默认值0，mysql不限制并发提交。
| innodb_compression_failure_threshold_pct | 5
#该参数和下面的参数来自facebook对压缩表的改进，当一个非压缩page无法压缩到指定size时，会产生索引分裂，这会大大影响性能，我们可以 给非压缩页留一些空白，少存一点数据，这样会降低压缩失败率，但也有可能减小压缩比，该选项表示当压缩失败率高于这个值时，进行apdative padding .
#当压缩失败rate大于这个值时，会增加padding来减小失败率，为0表示禁止该padding.
| innodb_compression_level | 6
#定义压缩表的压缩级别，在具有较好压缩特性的数据集上，可以适当调小该值，还获得更好的TPS性能
#可通过 innodb_compression_level 配置为 InnoDB 表选择 0-9 的不同压缩级别（默认值6）
| innodb_compression_pad_pct_max | 50
#一个page中最大允许留白的百分比
| innodb_concurrency_tickets | 5000
#直到线程用尽了这个值，在再次进入innodb时才需要检查
| innodb_data_file_path |
/data/mysql/ibdata1:12M;/data/mysql/innodb1/ibdata2:12M;/data/mysql/innodb2/ibdata3:12M;/data/mysql/innodb3/ibdata4:12M:autoextend:max:1G
| innodb_data_home_dir |
| innodb_deadlock_detect | ON
# 增加了innodb_deadlock_detect 参数，控制是否打开死锁检测。关闭死锁检测，在性能上有非常大的提高，曾经在其他mysql分支增加了这个参数，而官方版本直到5.7.15才增加了这个参数，默认是打开的。
| innodb_default_row_format | dynamic
# 5.6 及之前版本为 row_format 参数制定，5.7以后，由此替代：
#mysql中若一张表里面存在varchar、text以及其变形、blob以及其变形的字段的话，那么这个表其实也叫动态表，即该表的 row_format是dynamic，就是说每条记录所占用的字节是动态的。其优点节省空间，缺点增加读取的时间开销。反之，这张表叫静态表，该表 row_format为fixed,即每条记录占用字节一样。优点读取快，缺点浪费部分空间
所以，做搜索查询量大的表一般都以空间来换取时间，设计成静态表。
fixed--->dynamic: 这会导致CHAR变成VARCHAR
| innodb_disable_sort_file_cache | OFF
##设置该选项表示操作系统不对merge-sort的临时文件cache,使用O_DIRECT
| innodb_doublewrite | ON
#如果这个变量启用（默认启用），InnoDB存储所有数据 两次，首先写到 doublewrite buffer，然后到实际数据文件。对基准或需要高性能而不关心数据完整性或可能的失败可以使用 --skip-innodb_doublewrite关闭。
| innodb_fast_shutdown | 1
#InnoDB关闭模式。
如果该值为0,InnoDB缓慢关闭,在关闭之前，做一个完整的清洗和插入缓冲合并。
如果该值为1(默认),InnoDB在关闭时跳过这些操作,这一过程称为快速关闭。
如果该值为2,InnoDB冲洗日志和冷关闭,好像MySQL发生崩溃;提交事务不会丢失,但是崩溃恢复操作使下一次启动需要更长的时间。
缓慢关闭可能花几分钟,甚至在极端情况下几小时,大量的数据仍然被缓冲。在MySQL主版本之间升级或降级之前使用慢关闭技术,这样所有的数据文件做充分的准备,以防升级过程更新文件格式。
在紧急或故障情况下,数据冒着被破坏风险，使用 innodb_fast_shutdown=2,获得绝对最快关闭。
| innodb_file_format | Barracuda
#innodb 的文件格式为Antelope, innoDB-Plugin的文件格式为Barracuda, 如果开启8KB的数据压缩页，就必须设置为Barracuda , 以后会是Cheetah, 默认为Antelope, 可动态修改，建议改为 Barracuda。
注意： 必须采用 Barracuda 文件格式且独立表空间，才支持数据页的压缩。
| innodb_file_format_check | ON
#用来检查共享表空间文件格式，如果共享表空间的文件格式高于当前版本，并且 此参数为ON， 就会检查出有问题。 此参数默认为ON， 不支持动态修改。 建议默认值。
#该变量可以设置1和0，对应着服务在启动时，Innodb是否检查系统表空间的文件格式标志位（如： Antelope 或 Barracuda）。如果该标志被检查，并且比当前Innodb支持的值更高。会产生一个错误，并且Innodb 不能启动。如果不高，innodb会设置 innodb_file_format_max 的值到文件标志位。注意：尽管默认值有时被显示为ON或OFF,在您的配置文件或命令行总是用数值1或0将打开或关闭此选项。
| innodb_file_format_max | Barracuda
#在服务启动时，Innodb把这个变量的值设置给系统表空间的文件格式标志（如 Antelope 或 Barracuda）。如果服务用一个“higher”文件格式创建或打开一个表，把 innodb_file_format_max的值设置为表的标志
| innodb_file_per_table | ON
#innodb 默认在共享表空间中存放表和索引数据，使用此选项，你可以告知它将表的索引和数据存放在单独的文件里。
在MySQL的配置文件[mysqld]部分，增加innodb_file_per_table参数。
可以修改InnoDB为独立表空间模式，每个数据库的每个表都会生成一个数据空间。
独立表空间：
优点：
1．每个表都有自已独立的表空间。
2．每个表的数据和索引都会存在自已的表空间中。
3．可以实现单表在不同的数据库中移动。
4．空间可以回收（除drop table操作处，表空不能自已回收）
a) Drop table操作自动回收表空间，如果对于统计分析或是日值表，删除大量数据后可以通过:alter table TableName engine=innodb;回缩不用的空间。
b) 对于使innodb-plugin的Innodb使用turncate table也会使空间收缩。
c) 对于使用独立表空间的表，不管怎么删除，表空间的碎片不会太严重的影响性能，而且还有机会处理。
缺点：
单表增加过大，如超过100个G。
结论：
共享表空间在Insert操作上少有优势。其它都没独立表空间表现好。当启用独立表空间时，请合理调整一 下：innodb_open_files 。
InnoDB Hot Backup（冷备）的表空间cp不会面对很多无用的copy了。而且利用innodb hot backup及表空间的管理命令可以实现单现移动。
1.innodb_file_per_table设置.开启方法：
在my.cnf中[mysqld]下设置
innodb_file_per_table=1
2.查看是否开启：
mysql> show variables like ‘%per_table%’;
3.关闭独享表空间
innodb_file_per_table=0关闭独立的表空间
mysql> show variables like ‘%per_table%’;
| innodb_fill_factor | 100
| innodb_flush_log_at_timeout | 1
#每N秒写和冲洗事务日志，这个选项仅当设置innodb_flush_log_at_trx_commit 为2才有效，刷日志 innodb_flush_neighbors 该变量在MySQL5.6.6新增。
| innodb_flush_log_at_trx_commit | 1
# （说 明：如果是游戏服务器，建议此值设置为2；如果是对数据安全要求极高的应用，建议设置为1；设置为0性能最高，但如果发生故障，数据可能会有丢失的危险！ 默认值1的意思是每一次事务提交或事务外的指令都需要把日志写入（flush）硬盘，这是很费时的。特别是使用电池供电缓存 （Battery backed up cache）时。设成2对于很多运用，特别是从MyISAM表转过来的是可以的，它的意思是不写入硬盘而是写入系 统缓存。日志仍然会每秒flush到硬盘，所以你一般不会丢失超过1-2秒的更新。设成0会更快一点，但安全方面比较差，即使MySQL挂了也可能会丢失 事务的数据。而值2只会在整个操作系统挂了时才可能丢数据。）
| innodb_flush_method | O_DIRECT
##新参数，在IO时使用O_DIRECT，但不再随后做fsync，可以参考bug#45892的描述；这种配置不适合一些文件系统，因为metadata没有被fsync到磁盘。
| innodb_flush_neighbors | 1
#刷新领接页
工作原理：
当刷新一个脏页时，innodb会检测该页所在区（extent）的所有页，如果是脏页，那么一起进行刷新。
这样做，通过AIO将多个IO写入操作合并为一个IO操作。在传统机械磁盘下有着显著优势。
innodb_flush_neighbors 参数来控制是否开启。
| innodb_flush_sync | ON
| innodb_flushing_avg_loops | 30
#这个选项可以控制adaptive flush对工作负载变化的响应速度。在这么多次loop内，innodb会保持上次的刷新状态快照不变，增加这个值有助于刷新操作更加平稳，而减小这个值有助于对工作负载的变化更快的调整adaptive flush，不过，如果设置的过小的话，在突然增大/减小的工作的负载中，容易引起性能尖峰。
| innodb_force_load_corrupted | OFF
#在启动时让InnoDB加载那些标记为损坏的表。只在排除故障期间用于恢复数据,否则无法访问。当故障检修完成后,将此设置OFF并重新启动服务。
| innodb_force_recovery | 0
#因为日志已经损坏，这里采用非常规手段,首先修改innodb_force_recovery参数，使mysqld跳过恢复步骤，将mysqld 启动,将数据导出来然后重建数据库。
innodb_force_recovery可以设置为1-6,大的数字包含前面所有数字的影响。
1. (SRV_FORCE_IGNORE_CORRUPT):忽略检查到的corrupt页。
2. (SRV_FORCE_NO_BACKGROUND):阻止主线程的运行，如主线程需要执行full purge操作，会导致crash。
3. (SRV_FORCE_NO_TRX_UNDO):不执行事务回滚操作。
4. (SRV_FORCE_NO_IBUF_MERGE):不执行插入缓冲的合并操作。
5. (SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志，InnoDB存储引擎会将未提交的事务视为已提交。
6. (SRV_FORCE_NO_LOG_REDO):不执行前滚的操作。
注意
a 当设置参数值大于0后，可以对表进行select,create,drop操作,但insert,update或者delete这类操作是不允许的。
b 当innodb_purge_threads 和 innodb_force_recovery一起设置会出现一种loop现象:
#0 代表党MySql关闭时，InnoDB需要完成所有的full purge 和 merge insert buffer操作，这会需要一些时间。1 代表不需要完成上述的full purge ,merge insert buffer操作，但是在缓冲池的一些数据脏页还是会刷新到磁盘。2 代表不完成full purge ,merge insert buffer操作，也 不将缓冲池中的数据脏页写回磁盘，而是将日志都写入日志文件。这样不会有任何事物会丢失，但是Mysql数据库下次启动时，会执行recovery
参数Innodb_force_recovery影响了整个InnoDB存储引擎的恢复状况。默认0
| innodb_ft_aux_table |
#给Innodb 包含全文索引的表指定合格名称，你设置这个变量的名称格式为 db_name/table_name，然而INFORMATION_SCHEMA中的表 INNODB_FT_INDEX_TABLE, INNODB_FT_INDEX_CACHE, INNODB_FT_CONFIG,INNODB_FT_DELETED,和 INNODB_FT_BEING_DELETED 反映对指定表的索引搜索信息。该变量在MySQL5.6.4新增的。
| innodb_ft_cache_size | 8000000
#当创建一个InnoDB全文索引,用于存储解析文档在内存的缓存的大小。
| innodb_ft_enable_diag_print | OFF
| innodb_ft_enable_stopword | ON
#在创建索引的时，指定一组与InnoDB全文索引相关禁用词（stopwords）。如果innodb_ft_user_stopword_table 选项被设置,暂停词来自那张表。另外,如果innodb_ft_server_stopword_table选项被设置,暂停词来自那张表。否则,使用一个内置默认的暂停词组。
| innodb_ft_max_token_size | 84
| innodb_ft_min_token_size | 3
| innodb_ft_num_word_optimize | 2000
| innodb_ft_result_cache_limit | 2000000000
| innodb_ft_server_stopword_table |
| innodb_ft_sort_pll_degree | 2
| innodb_ft_total_cache_size | 640000000
| innodb_ft_user_stopword_table |
--innodb_ft_* 全部为全文索引相关信息。
| innodb_io_capacity | 4000
#默认是200， 单位是页，该设置大小取决与硬盘的IOPS。 如果6块15000转的磁盘RAID10， 可考虑设置为2000比较合适。
#单盘 sas/sata --> 200左右：（10000rpm转速）
#sas*12/raid10 -->2000
#ssd --> 5000
#pusion-io -->50000
| innodb_io_capacity_max | 8000
##当flush操作落后太多时，可能会做一些非常有侵略性的刷新（超过指定的innodb_io_capacity），这会影响到正常的业务，指定这个值，可以限制io capacity的上限，减少对正常应用的影响.
| innodb_large_prefix | ON
#对使用 DYNAMIC和COMPRESSED 行格式的InnoDB表，启用这个选项允许前缀索引 长度可以长于767字节（最大为3072字节）.(创建这些表也需要这些选项innodb_file_format=barracuda 和innodb_file_per_table=true.)在不同变量设置下，对应前缀索引的最大值见 Section 14.2.7, “Limits on InnoDB Tables” 。对使用REDUNDANT 和 COMPACT 行格式的表，这个选项不影响索引前缀所允许的长度。当这个选项被设置，当对REDUNDANT或COMPACT尝试创建一个索引大于3072，发生一个ER_INDEX_COLUMN_TOO_LONG (1727)错误
| innodb_lock_wait_timeout | 5
# 这是innodb等待行锁直到放弃的秒数，当超过innodb_lock_wait_timeout设定的值后，会返回错误“ERROR 1205(HY000):Lock wait timeout exceeded; try restarting transaction” 。
# 这设置很大防止查询失败，只会导致更严重问题，因为很多阻塞transaction 会相互锁住。
# 默认为50s(大多数支持默认或小一些)
| innodb_locks_unsafe_for_binlog | OFF
# 此变量定义innodb如何使用间隙锁来搜索和扫描索引，默认值（为0）,间隙锁开启。
# 推荐用READ COMMITTED 替代他，这个变量不能设置为session级别。
| innodb_log_buffer_size | 16777216
#这个参数就是用来设置 Innodb 的 Log Buffer 大小的，系统默认值为 1MB。Log Buffer 的主要作用就是缓冲 Log 数据，提高写 Log 的 IO 性能。一般来说，如果你的系统不是写负载非常高且以 大事务居多的话，8MB 以内的大小就完全足够了。
#如果完全从 Log Buffer 本身来说，自然是大一些会减少更多的磁盘 IO。但是由于 Log 本身是 为了保护数据安全而产生的，而 Log 从 Buffer 到磁盘的刷新频率和控制数据安全一致的事务直接相关， 并且也有相关参数来控制（innodb_flush_log_at_trx_commit）.
| innodb_log_checksums | ON
| innodb_log_compressed_pages | ON
#指定重压缩页的位图是否存储到Innodb redo logs。这个变量在MySQL5.6.11新增的
| innodb_log_file_size | 1073741824 (Kb)
#在一个日志组中每一个日志文件大小。日志文件合并后的大小（(innodb_log_file_size *innodb_log_files_in_group）可以到达512G。默认是48M。值明智范围从1MB到缓冲池的大小的1/n，N是日志文件组中文件数。值越大，在缓冲池执行checkpoint 刷新活动次数越小，节省磁盘I/O。日志文件越大，崩溃恢复越慢。尽管在MySQL5.5改善了恢复的性能和使日志文件更少考虑。
| innodb_log_files_in_group | 2
#在日志组的日志文件数。
| innodb_log_group_home_dir | /data/mysql/
#在日志组的日志路径
| innodb_log_write_ahead_size | 8192
#全局动态变量，默认8192，即8K，范围：512bytes～innodb_page_size，以字节为单位。
表示redo log写前的块大小。InnoDB以512字节一个block的方式对齐写入ib_logfile文件，但文件系统一般以4096字节为一个block单位。如果即将写入的日志文件块不在OS Cache时，就需要将对应的4096字节的block读入内存，修改其中的512字节，然后再把该block写回磁盘。该参数解决这个问题，当当前写入文件的偏移量不能整除该值时，则补0，多写一部分数据。这样当写入的数据是以磁盘block size对齐时，就可以直接write磁盘，而无需read-modify-write这三步了。
| innodb_lru_scan_depth | 2000
#影响page cleaner线程一次扫描LRU/UNZIP_LRU的深度，默认为1024，IO有空余可以适当调大;
| innodb_max_dirty_pages_pct | 75.000000
关闭数据库之前，可以手工调整@@global.innodb_max_dirty_pages_pct为比较小的数值，然后等待dity pages变少，然后restart，可以减少启动要恢复的时间。
对于很大的innodb buffer的，设置小点的innodb_max_dirty_pages_pct理论上是比较合理的。谁见过在oracle数据库 中，v$bh.dirty占到90%的。反正dirty buffer writer是backgound async的，只要不要太lazy或者crazy就行。
| innodb_max_dirty_pages_pct_lwm | 0.000000
#防止在到达innodb_max_dirty_pages_pct时疯狂刷新，而是在达到这样一个限定值时，开始“优雅”的做刷新脏页（预刷新）。详细见函数af_get_pct_for_dirty
#mysql检查点事件受两个因素的制约：一个是amount,另外一个是age.amount主要由 innodb_max_dirty_pages_pct参数控制;至于age,主要是由日志文件大小有关。
| innodb_max_purge_lag | 0
#该变量控制 purge 操作滞后多长，才延迟INSERT,UPDATE和DELETE 操作。默认是0（不延迟）。
InnoDB 事务系统维护一个事务列表。它记录被UPDATE 和DELETE 操作标志为删除的记录。这个列表的长度
代表 purge_lag值。当purge_lag超过innodb_max_purge_lag，每个 INSERT, UPDATE, 和 DELETE 操作被延迟。延迟的数量是 ((purge_lag/innodb_max_purge_lag)*10)-5 毫秒。在极端情况下 purge_lag 巨大，以防止过度延迟。你可以设置一个延迟的时间上限通过 innodb_max_purge_lag_delay 配置选项，延迟是从开始清洗批次计算,每十秒。如果由于旧一致性读 读到要清除的行，不能运行清除，则操作不能延迟。
滞后的值显示在InnoDB监控输出的事务部分中的 history list length。例如,如果输出包括以下行,滞后值是20:History list length 20
| innodb_max_purge_lag_delay | 0
#指定最大延迟时间毫秒。任何非零值表示一个基于innodb_max_purge_lag值计算延迟时间的上限。默认为零意味着没有强制延迟间隔的上限。
| innodb_max_undo_log_size | 1073741824
#控制最大undo tablespace文件的大小，超过这个阀值时才会去尝试truncate. truncate后的大小默认为10M
| innodb_monitor_disable |
#关闭 INFORMATION_SCHEMA.INNODB_METRICS 表中一个或更多计数器。
| innodb_monitor_enable |
#打开 INFORMATION_SCHEMA.INNODB_METRICS 表中一个或更多计数器。
| innodb_monitor_reset |
#重置INFORMATION_SCHEMA.INNODB_METRICS 表中一个或更多计数器的值为0.
| innodb_monitor_reset_all |
#重置INFORMATION_SCHEMA.INNODB_METRICS 表中一个或更多计数器所有值（最小，最大，等待）
| innodb_old_blocks_pct | 37
#指定buffer pool用于旧块分表的百分比。范围从5到95。默认是37（即pool的3/8）.通常结合innodb_old_blocks_time一起使用
| innodb_old_blocks_time | 1000
#全局动态变量。5.6.6之后默认是1000，之前是0。单位是毫秒。
#该参数表示等到该时间后，再读取该页则会进入到new端，有效的避免了对于上述SQL对BP的污染。默认是0，单位是毫秒。如设置为1000则表示：读到该页到midpoint的位置，要再等1秒之后读取该页才能进入new列表。而0则表示读取到该页则会直接被放入到new列表。具体的可以看这里。和innodb_old_blocks_pct配合使用，该参数默认是37（3/8），即BP的3/8处。
BP(Buffer_pool)
| innodb_online_alter_log_max_size | 134217728
# #online ddl时并发DML产生的row log最大size，超过这个限制会导致DDL回滚 .
#对InnoDB表在Online DDL 操作，临时日志文件最大值。每个索引创建或修改表都有这个日志文件，这个日志文件存储在DDL操作期间对表插入，更新，删除的数据。当 innodb_sort_buffer_siz的值需要，临时日志文件自动扩展直到innodb_online_alter_log_max_size指定的值。如果任何临时日志文件超过这个上限,ALTER TABLE操作失败和所有未提交的并发DML操作被回滚。因此在ONLINE DDL 操作期间，有大量DML并发，应该增大该值。但也导致结束DDL操作需要更长时间当表被锁用来从日志应用数据。
| innodb_open_files | 2000
#这变量仅与你使用InnoDB多表空间文件有关，它指定MySQL在一时间保持打开.ibd 文件数。最小值是10，自从MySQL5.6.6默认值是300.
| innodb_optimize_fulltext_only | OFF
#改变OPTIMIZE TABLE语句操作Innodb表的方法，对含有全文索引的innodb表的维护操作期间，临时启用改变量。默认情况， OPTIMIZE TABLE 会对有聚集索引表进行重新整理数据。当启用这选项，OPTIMIZE TABLE跳过表数据重新整理，仅对有全文索引的新增，更新和删除的数据进行处理。
| innodb_page_cleaners | 1
全局变量， 5.7.7之前默认1，5.7.8之后默认4，范围：1～64
表示刷写BP脏页的线程数，5.6.2开始从master线程中独立出来，5.7.4开始支持多线程flush。这个值必须小于等于innodb_buffer_pool_instances。
| innodb_page_size | 16384
#如果使用SSD或是固态盘需要考虑：
#innodb_page_size = 4K
#Innodb_flush_neighbors = 0
# Innodb page size 可以选择 8K、 16K、 32K、 64K。不过因为Innodb每个page都有不小的冗余空间，从空间和内存利用的角度来讲，page size越大越好。但是从checkpoint的角度来讲恰恰相反，page size越小，性能越好
| innodb_print_all_deadlocks | ON
# #保存全部死锁信息
| innodb_purge_batch_size | 300
# 当开启独立线程清除undo 页时，表示一次删除多少个页，默认是20，不支持动态修改，一般不需要修改。
#控制每次full purge回收的undo页的数量
| innodb_purge_rseg_truncate_frequency | 128
#控制回收(收缩)undo log的频率.undo log空间在它的回滚段没有得到释放之前不会收缩，
想要增加释放回滚区间的频率,就得降低innodb_purge_rseg_truncate_frequency设定值。
| innodb_purge_threads | 4
# purge线程数，可以加快purge速度
#从InnoDB 1.2版本开始，InnoDB支持多个Purge Thread，这样做的目的是为了进一步加快undo页的回收。同时由于Purge Thread需要离散地读取undo页，这样也能更进一步利用磁盘的随机读取性能。如用户可以设置4个Purge Thread：
#而其目的是为了减轻原Master Thread的工作及对于用户查询线程的阻塞，进一步提高InnoDB存储引擎的性能。
| innodb_random_read_ahead | OFF
#InnoDB 提供了两种预读的方式，一种是 Linear read ahead，由参数innodb_read_ahead_threshold控制，当你连续读取一个 extent 的 threshold 个 page 的时候，会触发下一个 extent 64个page的预读。另外一种是Random read-ahead，由参数innodb_random_read_ahead控制，当你连续读取设定的数量的page后，会触发读取这个extent的剩余page。
| innodb_read_ahead_threshold | 56
#当顺序读取extent块（包含64个page) innodb_read_ahead_threshold 设置的page页数量时，触发一个异步读取请求，将下一个页提前读取到buffer_pool 中。 默认为56， 不支持动态修改，一般采用默认。
| innodb_read_io_threads | 4
# 控制后台线程处理数据页上的写请求， 默认是4，不支持动态修改，建议根据服务器的核数以及读写请求 的比例加以调整。
而在MySQL5.5.x中用2个innodb_read_io_threads和Innodb_write_io_threads取代此版本之前参数，
该参数值之和=2*cpu个数*cpu核数;如果你的系统读>写,可以设置innodb_read_io_threads值相对大点;反之，也可以.
| innodb_read_only | OFF
#启动server 在read-only模式。对于分布在数据库应用或者数据设置为只读介质。
也可以用于数据仓库共享相同的数据目录在多个实例之间。
| read_only | OFF
当read_only 系统变量启用时, server 不允许client 更新除了用户有超级权限, 默认这个变量是关闭的。
| innodb_replication_delay | 0
# 当innodb_thread_concurrency 线程已满时，Slave 端复制线程的延迟时间（ms), 默认为0， 不延迟，可动态修改。
| innodb_rollback_on_timeout | OFF
# 当查询因锁定等待错误而中断时，最后一条语句回滚了，整个事物还没有终止，如果将该选项设置为1，将会改变此行为。
#innodb_rollback_on_timeout是啥作用？
答：事务B在锁等待超时后是回滚事务内所有的statement还是最后一条语句；
0表示rollback最后一条语句，默认值；有点坑
1表示回滚事务B内所有的statements；
此参数是只读参数，需在my.cnf中配置，并且重启生效；
注意：回滚statements后不自动commit或rollback事务；坑
#总结：
1，关闭innodb_rollback_on_timeout后，一旦以begin;start transaction;等语句开启一个事务，当锁等待超时后，该事务请求的锁将不释放，直到事务提交或回滚或会话超时；
所以autocommit参数建议设置成ON，只要程序没有显示开启事务，就可以避免上述锁未释放问题。
2、开启innodb_rollback_on_timeout后，一旦锁等待超时，是事务内sql将全部回滚，且释放之前请求的锁。
3、当autocommit=on，只要不显示开启事务，将不存在上面2个问题，即锁的问题和回滚的问题
| innodb_rollback_segments | 128
# 由innodb_undo_logs 替代:
| innodb_sort_buffer_size | 27108864
#specifies the size of sort buffers used for sorting data during creation of an InnoDB index.
| innodb_spin_wait_delay | 6
#参数的值默认是6，可动态调整。
#为了防止自旋锁循环过快，耗费CPU，在MySQL5.5.X版本里引入了innodb_spin_wait_delay参数，作用是控制轮训间 隔，也就是说在每次轮训的过程中，会休息一会儿然后再轮训。
| innodb_stats_auto_recalc | ON
#对InnoDB表统计信息持久化时，表的row发生变化大于
10%(counter > n_rows / 10 /* 10%)并且innodb_stats_auto_recalc=on，统计信信息会更新（虽然innodb_stats_auto_recalc=on是自动重新计算，但是也是异步的，可能会延时，比如当瞬间的DML批量操作就可能有延时） 2.统计信息非持久化还是和5.5 一致的（表的row发生变化大于1/16时更新统计信息）
| innodb_stats_method | nulls_equal
#计算统计信息时，拥有相同key prefix的行算作一个value group(类似oracle索引中的num_distinct，其值越多意味着索引选择性越好)，average group size是非常重要的指标，即平均一个索引值返回的表行数，主要有两个用途：
1估算每次ref access要读取多少行
2 估算一个partial join要产生多少行 (…) join tab on tab.key = expr
由此可知，average group size越高则索引选择性越低，表基数即value group数量计算公式为N/S(N:表行数 S:average group size)，可通过show index查看
除了主键，索引不可避免的会遇到Null(对于<=>操作符，NULL和Non-null被同等对待，而Null = Null则会返回false)，mysql将NULL视作无穷小；
收集统计信息时，为了灵活的处理Null，InnoDB/MyISAM各引入一个参数Innodb_stats_method/myisam_stats_method，分别三个候选值：nulls_equal/nulls_unequal/nulls_ignored(其中innod_stats_method只有全局变量)
Nulls_equal：所有Null都相等，即算作一个value group；若Null过多则会导致average group size偏大
Nulls_unequal：所有Null互不相同，每个算作一个value group；如果non-null group size过大且null数量过多，此设置会拉低整体的average group size，可能导致滥用索引
Nulls_ignored：忽略Null
对于已经收集的统计信息，无法分辨其采用了那种方式；对于非InnoDB/MyISAM表，只有一种收集方式，即nulls_equal；
手工收集统计信息需要调用analyze table，但若表自上次analye至今没有任何改动，即便调用此命令实际也不会收集统计信息，需先让统计信息过期(插入一行再删除即可)
Mysql也可自动收集，诸如bulk insert/delete以及某些alter table语句均会触发
如何查看统计信息
Show index from table或查看information_schema.statistics表
Show table status或information_schema.tables表
| innodb_stats_on_metadata | OFF
#默认是关闭了这个会对INFORMATION_SCHEMA中的一些表进行查询操作，以方便索引统计信息，如果读要求高的建议关闭
#也就是说，当使用 SHOW INDEX, SHOW TABLE STATUS and SHOW [FULL] TABLES时，会自动更新统计信息，或者对应的从 INFORMATION_SCHEMA.TABLES和INFORMATION_SCHEMA.STATISTICS 表中查询时。
#实际上这个动态统计的功能已经不推荐了，以后增加参数控制 DML 期间也不作动态统计了。因此这个参数配置成 off 更合理些
| innodb_stats_persistent | ON
#优化器永久统计信息通过把统计信息保存在磁盘上，使得MySQL在选择语句的执行计划时，会选择相对一致的执行计划，提升了SQL执行计划的稳定性。
当开启innodb_stats_persistent=ON这个参数时或在建表时带了STATS_PERSISTENT=1参数，优化器的统计信息会永久保存到磁盘上。
| innodb_stats_persistent_sample_pages | 20
#每次采样的块数，默认为20
| innodb_stats_sample_pages | 8
#每次收集统计信息时采样的页数，默认为8
| innodb_stats_transient_sample_pages | 8
#默认为8个，取8个页块，分析结果作为统计信息
| innodb_status_output | OFF
| innodb_status_output_locks | OFF
# InnoDB各类监控输出结果
#仅在必要时开启，因为会造成性能开销，观察结束后切记关闭监控。若监控期间服务器重新启动，则监控不会自动开启，需删除原来的表并重建相关表，或者重新设置相关变量。表结构不重要，重要的是名字和需为InnoDB引擎。
#有四类InnoDB monitor：Standard Monitor、Lock Monitor、Tablespace Monitor、Table Monitor。其中Tablespace Monitor和Table Monitor将在后续版本（MySQL5.7中移除，对应的信息可从information_schema的表中获取）
Standard Monitor：监视活动事务持有的表锁、行锁；事务锁等待；线程信号量等待；文件IO请求；buffer pool统计信息；InnoDB主线程purge和change buffer merge活动。
Lock Monitor：提供额外的锁信息。
Tablespace Monitor：显示共享表空间中的文件段以及表空间数据结构配置验证。
Table Monitor：显示内部数据字典的内容。
# show engine innodb status\G; --显示更多关于监控信息，当打开后。
(root@(none)) Mysql >SET GLOBAL innodb_status_output=ON;
Query OK, 0 rows affected (0.00 sec)
(root@(none)) Mysql >SHOW variables like 'innodb_status_output';
+----------------------+-------+
| Variable_name | Value |
+----------------------+-------+
| innodb_status_output | ON |
+----------------------+-------+
1 row in set (0.00 sec)
(root@(none)) Mysql >show engine innodb status\G;
*************************** 1. row ***************************
Type: InnoDB
Name:
Status:
=====================================
2017-03-15 16:12:04 0x7fad2c2f5700 INNODB MONITOR OUTPUT
=====================================
| innodb_strict_mode | ON
#这个设置让MYSQL在某些条件下把告警改成抛错，尤其是无效的或者可能有风险的 create table 选项。 如果打开这个，就会检查 create table选项。
| innodb_support_xa | ON
# #innodb_support_xa 设置为1，标志支持分布式事物，主要保证binary log和其他引擎的主事务数据保持一致性，属于同步操作；如果你设置0，就是异步操作，这样就会一定程度上减少磁盘的刷新次数和磁盘的竞争
| innodb_sync_array_size | 1
#信号量等待队列最大长度
| innodb_sync_spin_loops | 30
#innodb_sync_spin_loops参数是自旋锁的轮转数，可以通过show engine innodb status来查看。相较于系统等待，自旋锁是低成本的等待；不过它是一个活跃的等待，会浪费一些cpu资源。因此如果看到大量的自旋等待和自旋轮转，则很显然它浪费了很多cpu资源。浪费cpu时间和无谓的上下文切换之间可以通过该值来平衡。
| innodb_table_locks | ON
#此变量定了innodb如何处理LOCK TABLES语句发出的表锁请求，默认（开启）立刻返回并且内部将表锁住。
当设置为0 时，他会接受lock table语句请求，但是直到所有锁释放后才从lock tables ... write返回。
| innodb_temp_data_file_path | ibtmp1:12M:autoextend
| innodb_thread_concurrency | 64
#InnoDB内核中同时可以允许最大的在线程数量（0表示没有限制），2*（CPU核数+磁盘数量）在理论上是一个合理的值，在实际应用中设置的更小一点可能会让性能更好一点。
#max_connections :
--允许服务器最大连接数，尽量不要设置很大。
MySQL数据库服务最大线程连接数参数max_connections，一般情况下都会设置在128-1024的范围，再结合实际业务可能的最大事务并发度，innodb_concurrency_tickets保持默认值一般情况下足够。
innodb_thread_concurrency = 0时(表示默然情况下，不限制线程并发执行数量），innodb_thread_sleep_delay参数就无效了。同样innodb_concurrency_tickets也没了意义，这里推荐设置innodb_thread_concurrency为0，这样可以更好地发挥CPU多核处理能力，提高并发量。
| innodb_thread_sleep_delay | 0
#线程首先睡眠innodb _thread_sleep_delay所规定的时间（微妙），然后再次尝试进入，如果还是不能进入，就会就进入一个等待队列并且把控制权限交给操作系统。
| innodb_tmpdir |
# tmpdir 目录
| innodb_undo_directory | /data/mysql/
#undo 目录
| innodb_undo_log_truncate | ON
#参数设置为1，即开启在线回收（收缩）undo log日志文件，支持动态设置。
| innodb_undo_logs | 128
#用于表示回滚段的个数（早期版本的命名为innodb_rollback_segments ），该变量可以动态调整，但是物理上的回滚段不会减少，只是会控制用到的回滚段的个数;
默认为128个回滚段
| innodb_undo_tablespaces | 0
#参数必须大于或等于2，即回收（收缩）一个undo log日志文件时，要保证另一个undo log是可用的。
#innoDB 设置独立UNDO 表空间：会有回滚操作
作为支持事务的存储引擎，必不可少， 设置独立undo 主要涉及2 个参数：
> 1 . innodb_undo_directory ：用于指定保存UNDO 日志的物理文件的位置。
> 2 . innodb_undo_tablespaces ： 用于指定 undo 表空间的数量，每个undo表空间都是一个独立的.idb文件。
此外， 还增加 innodb_undo_logs 的系统参数， 用于指定UNDO 表空间中回滚段的数量。（innodb_rollback_segments 为旧此相同功能参数，兼容以前版本）
undo 目前（5.6） 一旦创建，就不能删除，同时也不能降级到5.6 之前的版本。
| innodb_use_native_aio | ON
# 此项默认开启，推荐不改变。如果遇见操作系统异步I/O子系统的问题，阻止innodb启动，你可以将它关闭。
| innodb_version | 5.7.16
| innodb_write_io_threads | 4
+------------------------------------------+-----------------------------------------------------------------------------------------------
131 rows in set (0.00 sec)
+-------------------------+------------------------------+
| Variable_name | Value |
+-------------------------+------------------------------+
| version | 5.7.16-log |
| version_comment | MySQL Community Server (GPL) |
| version_compile_machine | x86_64 |
| version_compile_os | linux-glibc2.5 |
+-------------------------+------------------------------+
4 rows in set (0.00 sec)
(root@(none)) Mysql >show variables like 'innodb_%';
+------------------------------------------+-----------------------------------------------------------------------------------------------
| Variable_name | Value
+------------------------------------------+-----------------------------------------------------------------------------------------------
| innodb_adaptive_flushing | ON
#innodb_io_capacity, innodb_max_dirty_pages_pct,innodb_adaptive_flushing这三个参数是为了解决SSD等大容量存储设备的出现而导致innoDB不能很好利用这类设备性能的困境而出现的，本文会结合mysql-5.5.34的源代码进行这三个参数的介绍。
#指定是否要根据负荷动态地调整InnoDB缓冲池中的刷新垃圾页面率。动态地调整垃圾页面率是为了避免突发的I/O并发量。该设置默认为启用。
| innodb_adaptive_flushing_lwm | 10
# 当自适应刷新功能开启时，低水位线表示重做日志的能力的百分比。
#该值表示redo log的一个最低容量限制百分比，默认为10，当没有达到这个值时，则不会page cleaner线程不会根据redo来判断是否刷页，细节见函数af_get_pct_for_lsn
| innodb_adaptive_hash_index | ON
#无论InnoDB adaptive hash index是启用还是关闭，需要根据负荷来判断，通过动态地开关 adaptive hash indexing来提高查询功能。由于adaptive hash index不是对所有的负荷都起作用，需根据实际的负荷来控制它启动和关闭的基准。详情请见14.2.13.6, “Adaptive Hash Indexes”。
该设置默认为启用。只需通过修改GLOBAL配置项来修改，不需要重启服务器。修改改配置需有超级权限。你也可以在服务器通过--skip-innodb_adaptive_hash_index来关闭该功能。
关闭the adaptive hash index，散列表将被立即清空。虽然散列表被清空但正常的操作仍然能继续。之前通过散列表执行的查询而现在将通过B-trees索引查询。当the adaptive hash index重启时，普通操作时将再次使用散列表。
S| innodb_adaptive_hash_index_parts | 8
| innodb_adaptive_max_sleep_delay | 150000
#允许InnoDB根据现有负荷自动调整 innodb_thread_sleep_delay值的大小。任何一个非零的值都允许自动使能，动态的调整 innodb_thread_sleep_delay的值，最高值可达 innodb_thread_sleep_delay配置的最大值。在大于16线程并发的InnoDB这样繁忙的系统中，这一配置项很有作用。（在实践中，有数百或成千上万的并发连接MySQL系统，它是最有价值的）
| innodb_api_bk_commit_interval | 5
# 在短时间内，多久通过InnoDB memcached 界面自动提交空闲连接。（5.6.17引入）
| innodb_api_disable_rowlock | OFF
#当innodb 分页式缓存执行DML操作的时候，使用这个变量去禁用行级锁。默认情况下innodb_api_disable_rowlocky设置为off, 这意味着分页式缓存请求获取和设置操作的行锁。当innodb_api_disable_rowlock 设置为on ，分页式缓存请求表锁而来代替行锁。
Innodb_api_disable_rowlock选项不是动态，它必须指定在mydqld命令行或MYSQL配置文件设置。插件安装后配置才会有效，在配置该参数需要重启数据库服务生效。
| innodb_api_enable_binlog | OFF
#允许您使用innodb memcached插件和mysql binary log
#Lets you use the InnoDB memcached plugin with the MySQL binary log. See Section 14.18,“InnoDB Integration with memcached” forusage details for this option.
#https://dev.mysql.com/doc/refman/5.6/en/innodb-memcached.html
| innodb_api_enable_mdl | OFF
#锁表被用于InnoDB分布式缓存插件中。因此可以在SQL接口被DDL去掉和修改。
| innodb_api_trx_level | 0
# 允许在分布式缓存接口处理中控制独立事务处理等级。细节请参看Section 14.18, “InnoDB Integration with memcached
一些数值的含义为：
§ 0 = READ UNCOMMITTED
§ 1 = READ COMMITTED
§ 2 = REPEATABLE READ
§ 3 = SERIALIZABLE
| innodb_autoextend_increment | 64
#当内存空间满时，增量空间被用来扩展InnoDB system tablespace，在MySQL5.6.6, 8之前默认值为64(M)，如果你设置innodb_file_per_table=1。
这个变量将不会在你创建的tablespace 文件里生效。这此文件是自动扩展的，不会参照innodb_autoextend_increment 值。初始化的扩展非常小，当扩展发生时增至4MB。
| innodb_autoinc_lock_mode | 1
# 此方式为innodb在插入自增字段时用到的锁定方式, 有三种模式，traditional(5.1 before),consecutive(5.1 begin default),interleaved,
# consecutive 是最安全，其他两种类型往往获得更好性能。
# 结论：innodb_autoinc_lock_mode为0时的，也就是官方说的traditional级别，该自增锁是表锁级别，且必须等待当前SQL执行完成后或者回滚掉才会释放，这样在高并发的情况下可想而知自增锁竞争是比较大的。
# 结论：innodb_autoinc_lock_mode为1时的，也就是官方说的consecutive级别，这时如果是单一的insert SQL，可以立即获得该锁，并立即释放，而不必等待当前SQL执行完成（除非在其他事务中已经有session获取了自增锁）。另外当SQL是一些批量insert sql时，比如insert into ...select ...,load data,replace ..select..时，这时还是表级锁，可以理解成退化为必须等待当前SQL执行完才释放。
可以认为，该值为1时是相对比较轻量的锁，也不会对复制产生影响，唯一的缺陷是产生的自增值不一定是完全连续的（不过个人认为这个往往不是很重要，也没必要根据自增id值来统计行数之类）。
# 结论：当innodb_autoinc_lock_mode设置为2时，所有insert种类的SQL都可以立马获得锁并释放，这时的效率最高。但是会引入一个新的问题：当binlog_format为statement时，这时的复制没法保证安全，因为批量的insert，比如insert ..select..语句在这个情况下，也可以立马获取到一大批的自增id值，不必锁整个表，slave在回放这个sql时必然会产生错乱。
但是反应到从库时，因为是基于statement的复制，必然出现主键冲突。
总结：1 innodb row复制时，可将innodb_autoinc_lock_mode设置为2，这时可在所有insert情况下表获得最大并发度
2 innodb statement复制时，可将innodb_autoinc_lock_mode设置为1，保证复制安全的同时，获得简单insert语句的最大并发度
3 myisam引擎情况下，无论什么样自增id锁都是表级锁，设置innodb_autoinc_lock_mode参数无效。
4 实际上提问者说到的在innodb引擎下自增id值作为主键的情况下，相比uuid或者自定义的主键，是可以提到插入速度的，因为innodb是主键聚集索引，实际的主键值必须按照主键顺序存取，那么自增id本身就是升序的，那么在插入数据时，底层就不必再做额外的排序操作，也减少了索引页分裂的次数，从而大大增加insert速度（除非其他方案也能保证主键完全自增）。
| innodb_buffer_pool_chunk_size | 134217728
#(5.7 引入)，MySQL 5.7.5后Innodb_buffer_pool_size一方面可以动态分配。但另一方面也引入了一个新特性，Innodb_buffer_pool_size分配必须是innodb_buffer_pool_chunk_size的倍数。同时最好是：innodb_buffer_pool_chunk_size*innodb_buffer_pool_instances.
默认为128M
| innodb_buffer_pool_dump_at_shutdown | ON
#解释：在关闭时把热数据dump到本地磁盘。
| innodb_buffer_pool_dump_now | OFF
#解释：采用手工方式把热数据dump到本地磁盘。
| innodb_buffer_pool_dump_pct | 40
#mysql5.7开始默认在数据库服务启动，停止时，预热与dump数据,设置dump的百分比，这部分数据是最热的数据.
#表示转储每个bp instance LRU上最热的page的百分比。通过设置该参数可以减少转储的page数。
| innodb_buffer_pool_filename | ib_buffer_pool
# 如果开启InnoDB预热功能，停止MySQL服务时，MySQL将InnoDB缓冲池中的热数据保存到数据库根目录中，默认文件名为ib_buffer_pool.
| innodb_buffer_pool_instances | 1
#innodb_buffer_pool_instances可以开启多个内存缓冲池，把需要缓冲的数据hash到不同的缓冲池中，这样可以并行的内存读写.
为了更好的并发性能，通过指定innodb_buffer_pool_instances（该值取值范围为1-64）创建多个缓存池，每个缓存池的大小为
innodb_buffer_pool_size/innodb_buffer_pool_instances，通常需要保持当个缓存池的大小大于1GB。
| innodb_buffer_pool_load_abort | OFF
#默认为关闭OFF。如果开启该参数，即便开启InnoDB预热功能，启动MySQL服务室，MySQL也不会将本地硬盘的热数据加载到InnoDB缓冲池中。
| innodb_buffer_pool_load_at_startup | ON
#解释：在启动时把热数据加载到内存。
| innodb_buffer_pool_load_now | OFF
#解释：采用手工方式把热数据加载到内存。
| innodb_buffer_pool_size | 536870912
# 调整innodb_buffer_pool_size大小，如果是单实例且绝大多数是InnoDB引擎表的话，可考虑设置为物理内存的50% ~ 75%左右；
#缓存数据块和索引块，对InnoDB表性能影响最大。通过查询show status like 'Innodb_buffer_pool_read%'，保证 (Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests越高越好.
#假设是一台单独给 MySQL 使用的主机，物理内存总大小为 8G，MySQL 最大连接数为 500，同时还使用 了 MyISAM 存储引擎，这时候我们的整体内存该如何分配呢？
内存分配为如下几大部分：
a) 系统使用，假设预留 800M；
b) 线程独享，约 2GB = 500 * (1MB + 1MB + 1MB + 512KB + 512KB)，组成大概如下:sort_buffer_size：1MB join_buffer_size：1MB read_buffer_size：1MB read_rnd_buffer_size：512KB thread_statck：512KB
c) MyISAM Key Cache，假设大概为 1.5GB；
d) Innodb Buffer Pool 最大可用量：8GB - 800MB - 2GB - 1.5GB = 3.7GB；
假设这个时候我们还按照 50%～80%的建议来设置，最小也是 4GB，而通过上面的估算，最大可用值 在 3.7GB 左右，那么很可能在系统负载很高当线程独享内存差不多出现极限情况的时候，系统很可能就 会出现内存不足的问题了
| innodb_change_buffer_max_size | 25
# 如果是日值类服务，可以考虑把这个增值调到 50
| innodb_change_buffering | all
#默认即可
#5.5之前。这还不叫change buffer，而是insert buffer；
#当更新/插入的非聚集索引的数据所对应的页不在内存中时（对非聚集索引的更新操作通常会带来随机IO），会将其放到一个insert buffer中，当随后页面被读到内存中时，会将这些变化的记录merge到页中。当服务器比较空闲时，后台线程也会做merge操作
但insert buffer会占用buffer pool，并且在非聚集索引很少时，并不总是必要的，反而会降低buffer pool做data cache的能力，
根据官方文档的描述，主要包括以下几个值：
1.all
The default value: buffer inserts, delete-marking operations, and purges.
2.none
Do not buffer any operations.
3.inserts
Buffer insert operations.
4.deletes
Buffer delete-marking operations.（包括delete和update操作）
5.changes
Buffer both inserts and delete-marking.
6.purges
Buffer the physical deletion operations that happen in the background
| innodb_checksum_algorithm | crc32
#Innodb引入了新的checksum计算方式，checksum算法由新参数 innodb_checksum_algorithm来控制，默认为crc32算法，主要有两种算法，一种是老的计算方法(innodb_checksum_algorithm=innodb)，使用这种算法是兼容老版本的MySQL。
因为使用了不同的算法计算checksum，会导致校验page失败。
| innodb_checksums | ON
#InnoDB在所有对磁盘的页面读取上使用校验和验证以确保额外容错防止硬件损坏或数据文件
| innodb_cmp_per_index_enabled | OFF
##表示是否统计每个表的每个索引的压缩状态，如果打开，信息会进行收集，并显示在information_schema的INNODB_CMP_PER_INDEX/INNODB_CMP_PER_INDEX_RESET中，这会有一定的性能损耗 .
| innodb_commit_concurrency | 0
#如你所见innodb_commit_concurrency仅用来保护行访问，使用内部结构和锁定分阶段提交，他仍是为保护变量。他限制innodb内核激活线程的commit。一个最佳的值也依赖很多其他因素。但是从5.1.36开始mysql不允许将该值设置为非0，该值只能为默认值0，mysql不限制并发提交。
| innodb_compression_failure_threshold_pct | 5
#该参数和下面的参数来自facebook对压缩表的改进，当一个非压缩page无法压缩到指定size时，会产生索引分裂，这会大大影响性能，我们可以 给非压缩页留一些空白，少存一点数据，这样会降低压缩失败率，但也有可能减小压缩比，该选项表示当压缩失败率高于这个值时，进行apdative padding .
#当压缩失败rate大于这个值时，会增加padding来减小失败率，为0表示禁止该padding.
| innodb_compression_level | 6
#定义压缩表的压缩级别，在具有较好压缩特性的数据集上，可以适当调小该值，还获得更好的TPS性能
#可通过 innodb_compression_level 配置为 InnoDB 表选择 0-9 的不同压缩级别（默认值6）
| innodb_compression_pad_pct_max | 50
#一个page中最大允许留白的百分比
| innodb_concurrency_tickets | 5000
#直到线程用尽了这个值，在再次进入innodb时才需要检查
| innodb_data_file_path |
/data/mysql/ibdata1:12M;/data/mysql/innodb1/ibdata2:12M;/data/mysql/innodb2/ibdata3:12M;/data/mysql/innodb3/ibdata4:12M:autoextend:max:1G
| innodb_data_home_dir |
| innodb_deadlock_detect | ON
# 增加了innodb_deadlock_detect 参数，控制是否打开死锁检测。关闭死锁检测，在性能上有非常大的提高，曾经在其他mysql分支增加了这个参数，而官方版本直到5.7.15才增加了这个参数，默认是打开的。
| innodb_default_row_format | dynamic
# 5.6 及之前版本为 row_format 参数制定，5.7以后，由此替代：
#mysql中若一张表里面存在varchar、text以及其变形、blob以及其变形的字段的话，那么这个表其实也叫动态表，即该表的 row_format是dynamic，就是说每条记录所占用的字节是动态的。其优点节省空间，缺点增加读取的时间开销。反之，这张表叫静态表，该表 row_format为fixed,即每条记录占用字节一样。优点读取快，缺点浪费部分空间
所以，做搜索查询量大的表一般都以空间来换取时间，设计成静态表。
fixed--->dynamic: 这会导致CHAR变成VARCHAR
| innodb_disable_sort_file_cache | OFF
##设置该选项表示操作系统不对merge-sort的临时文件cache,使用O_DIRECT
| innodb_doublewrite | ON
#如果这个变量启用（默认启用），InnoDB存储所有数据 两次，首先写到 doublewrite buffer，然后到实际数据文件。对基准或需要高性能而不关心数据完整性或可能的失败可以使用 --skip-innodb_doublewrite关闭。
| innodb_fast_shutdown | 1
#InnoDB关闭模式。
如果该值为0,InnoDB缓慢关闭,在关闭之前，做一个完整的清洗和插入缓冲合并。
如果该值为1(默认),InnoDB在关闭时跳过这些操作,这一过程称为快速关闭。
如果该值为2,InnoDB冲洗日志和冷关闭,好像MySQL发生崩溃;提交事务不会丢失,但是崩溃恢复操作使下一次启动需要更长的时间。
缓慢关闭可能花几分钟,甚至在极端情况下几小时,大量的数据仍然被缓冲。在MySQL主版本之间升级或降级之前使用慢关闭技术,这样所有的数据文件做充分的准备,以防升级过程更新文件格式。
在紧急或故障情况下,数据冒着被破坏风险，使用 innodb_fast_shutdown=2,获得绝对最快关闭。
| innodb_file_format | Barracuda
#innodb 的文件格式为Antelope, innoDB-Plugin的文件格式为Barracuda, 如果开启8KB的数据压缩页，就必须设置为Barracuda , 以后会是Cheetah, 默认为Antelope, 可动态修改，建议改为 Barracuda。
注意： 必须采用 Barracuda 文件格式且独立表空间，才支持数据页的压缩。
| innodb_file_format_check | ON
#用来检查共享表空间文件格式，如果共享表空间的文件格式高于当前版本，并且 此参数为ON， 就会检查出有问题。 此参数默认为ON， 不支持动态修改。 建议默认值。
#该变量可以设置1和0，对应着服务在启动时，Innodb是否检查系统表空间的文件格式标志位（如： Antelope 或 Barracuda）。如果该标志被检查，并且比当前Innodb支持的值更高。会产生一个错误，并且Innodb 不能启动。如果不高，innodb会设置 innodb_file_format_max 的值到文件标志位。注意：尽管默认值有时被显示为ON或OFF,在您的配置文件或命令行总是用数值1或0将打开或关闭此选项。
| innodb_file_format_max | Barracuda
#在服务启动时，Innodb把这个变量的值设置给系统表空间的文件格式标志（如 Antelope 或 Barracuda）。如果服务用一个“higher”文件格式创建或打开一个表，把 innodb_file_format_max的值设置为表的标志
| innodb_file_per_table | ON
#innodb 默认在共享表空间中存放表和索引数据，使用此选项，你可以告知它将表的索引和数据存放在单独的文件里。
在MySQL的配置文件[mysqld]部分，增加innodb_file_per_table参数。
可以修改InnoDB为独立表空间模式，每个数据库的每个表都会生成一个数据空间。
独立表空间：
优点：
1．每个表都有自已独立的表空间。
2．每个表的数据和索引都会存在自已的表空间中。
3．可以实现单表在不同的数据库中移动。
4．空间可以回收（除drop table操作处，表空不能自已回收）
a) Drop table操作自动回收表空间，如果对于统计分析或是日值表，删除大量数据后可以通过:alter table TableName engine=innodb;回缩不用的空间。
b) 对于使innodb-plugin的Innodb使用turncate table也会使空间收缩。
c) 对于使用独立表空间的表，不管怎么删除，表空间的碎片不会太严重的影响性能，而且还有机会处理。
缺点：
单表增加过大，如超过100个G。
结论：
共享表空间在Insert操作上少有优势。其它都没独立表空间表现好。当启用独立表空间时，请合理调整一 下：innodb_open_files 。
InnoDB Hot Backup（冷备）的表空间cp不会面对很多无用的copy了。而且利用innodb hot backup及表空间的管理命令可以实现单现移动。
1.innodb_file_per_table设置.开启方法：
在my.cnf中[mysqld]下设置
innodb_file_per_table=1
2.查看是否开启：
mysql> show variables like ‘%per_table%’;
3.关闭独享表空间
innodb_file_per_table=0关闭独立的表空间
mysql> show variables like ‘%per_table%’;
| innodb_fill_factor | 100
| innodb_flush_log_at_timeout | 1
#每N秒写和冲洗事务日志，这个选项仅当设置innodb_flush_log_at_trx_commit 为2才有效，刷日志 innodb_flush_neighbors 该变量在MySQL5.6.6新增。
| innodb_flush_log_at_trx_commit | 1
# （说 明：如果是游戏服务器，建议此值设置为2；如果是对数据安全要求极高的应用，建议设置为1；设置为0性能最高，但如果发生故障，数据可能会有丢失的危险！ 默认值1的意思是每一次事务提交或事务外的指令都需要把日志写入（flush）硬盘，这是很费时的。特别是使用电池供电缓存 （Battery backed up cache）时。设成2对于很多运用，特别是从MyISAM表转过来的是可以的，它的意思是不写入硬盘而是写入系 统缓存。日志仍然会每秒flush到硬盘，所以你一般不会丢失超过1-2秒的更新。设成0会更快一点，但安全方面比较差，即使MySQL挂了也可能会丢失 事务的数据。而值2只会在整个操作系统挂了时才可能丢数据。）
| innodb_flush_method | O_DIRECT
##新参数，在IO时使用O_DIRECT，但不再随后做fsync，可以参考bug#45892的描述；这种配置不适合一些文件系统，因为metadata没有被fsync到磁盘。
| innodb_flush_neighbors | 1
#刷新领接页
工作原理：
当刷新一个脏页时，innodb会检测该页所在区（extent）的所有页，如果是脏页，那么一起进行刷新。
这样做，通过AIO将多个IO写入操作合并为一个IO操作。在传统机械磁盘下有着显著优势。
innodb_flush_neighbors 参数来控制是否开启。
| innodb_flush_sync | ON
| innodb_flushing_avg_loops | 30
#这个选项可以控制adaptive flush对工作负载变化的响应速度。在这么多次loop内，innodb会保持上次的刷新状态快照不变，增加这个值有助于刷新操作更加平稳，而减小这个值有助于对工作负载的变化更快的调整adaptive flush，不过，如果设置的过小的话，在突然增大/减小的工作的负载中，容易引起性能尖峰。
| innodb_force_load_corrupted | OFF
#在启动时让InnoDB加载那些标记为损坏的表。只在排除故障期间用于恢复数据,否则无法访问。当故障检修完成后,将此设置OFF并重新启动服务。
| innodb_force_recovery | 0
#因为日志已经损坏，这里采用非常规手段,首先修改innodb_force_recovery参数，使mysqld跳过恢复步骤，将mysqld 启动,将数据导出来然后重建数据库。
innodb_force_recovery可以设置为1-6,大的数字包含前面所有数字的影响。
1. (SRV_FORCE_IGNORE_CORRUPT):忽略检查到的corrupt页。
2. (SRV_FORCE_NO_BACKGROUND):阻止主线程的运行，如主线程需要执行full purge操作，会导致crash。
3. (SRV_FORCE_NO_TRX_UNDO):不执行事务回滚操作。
4. (SRV_FORCE_NO_IBUF_MERGE):不执行插入缓冲的合并操作。
5. (SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志，InnoDB存储引擎会将未提交的事务视为已提交。
6. (SRV_FORCE_NO_LOG_REDO):不执行前滚的操作。
注意
a 当设置参数值大于0后，可以对表进行select,create,drop操作,但insert,update或者delete这类操作是不允许的。
b 当innodb_purge_threads 和 innodb_force_recovery一起设置会出现一种loop现象:
#0 代表党MySql关闭时，InnoDB需要完成所有的full purge 和 merge insert buffer操作，这会需要一些时间。1 代表不需要完成上述的full purge ,merge insert buffer操作，但是在缓冲池的一些数据脏页还是会刷新到磁盘。2 代表不完成full purge ,merge insert buffer操作，也 不将缓冲池中的数据脏页写回磁盘，而是将日志都写入日志文件。这样不会有任何事物会丢失，但是Mysql数据库下次启动时，会执行recovery
参数Innodb_force_recovery影响了整个InnoDB存储引擎的恢复状况。默认0
| innodb_ft_aux_table |
#给Innodb 包含全文索引的表指定合格名称，你设置这个变量的名称格式为 db_name/table_name，然而INFORMATION_SCHEMA中的表 INNODB_FT_INDEX_TABLE, INNODB_FT_INDEX_CACHE, INNODB_FT_CONFIG,INNODB_FT_DELETED,和 INNODB_FT_BEING_DELETED 反映对指定表的索引搜索信息。该变量在MySQL5.6.4新增的。
| innodb_ft_cache_size | 8000000
#当创建一个InnoDB全文索引,用于存储解析文档在内存的缓存的大小。
| innodb_ft_enable_diag_print | OFF
| innodb_ft_enable_stopword | ON
#在创建索引的时，指定一组与InnoDB全文索引相关禁用词（stopwords）。如果innodb_ft_user_stopword_table 选项被设置,暂停词来自那张表。另外,如果innodb_ft_server_stopword_table选项被设置,暂停词来自那张表。否则,使用一个内置默认的暂停词组。
| innodb_ft_max_token_size | 84
| innodb_ft_min_token_size | 3
| innodb_ft_num_word_optimize | 2000
| innodb_ft_result_cache_limit | 2000000000
| innodb_ft_server_stopword_table |
| innodb_ft_sort_pll_degree | 2
| innodb_ft_total_cache_size | 640000000
| innodb_ft_user_stopword_table |
--innodb_ft_* 全部为全文索引相关信息。
| innodb_io_capacity | 4000
#默认是200， 单位是页，该设置大小取决与硬盘的IOPS。 如果6块15000转的磁盘RAID10， 可考虑设置为2000比较合适。
#单盘 sas/sata --> 200左右：（10000rpm转速）
#sas*12/raid10 -->2000
#ssd --> 5000
#pusion-io -->50000
| innodb_io_capacity_max | 8000
##当flush操作落后太多时，可能会做一些非常有侵略性的刷新（超过指定的innodb_io_capacity），这会影响到正常的业务，指定这个值，可以限制io capacity的上限，减少对正常应用的影响.
| innodb_large_prefix | ON
#对使用 DYNAMIC和COMPRESSED 行格式的InnoDB表，启用这个选项允许前缀索引 长度可以长于767字节（最大为3072字节）.(创建这些表也需要这些选项innodb_file_format=barracuda 和innodb_file_per_table=true.)在不同变量设置下，对应前缀索引的最大值见 Section 14.2.7, “Limits on InnoDB Tables” 。对使用REDUNDANT 和 COMPACT 行格式的表，这个选项不影响索引前缀所允许的长度。当这个选项被设置，当对REDUNDANT或COMPACT尝试创建一个索引大于3072，发生一个ER_INDEX_COLUMN_TOO_LONG (1727)错误
| innodb_lock_wait_timeout | 5
# 这是innodb等待行锁直到放弃的秒数，当超过innodb_lock_wait_timeout设定的值后，会返回错误“ERROR 1205(HY000):Lock wait timeout exceeded; try restarting transaction” 。
# 这设置很大防止查询失败，只会导致更严重问题，因为很多阻塞transaction 会相互锁住。
# 默认为50s(大多数支持默认或小一些)
| innodb_locks_unsafe_for_binlog | OFF
# 此变量定义innodb如何使用间隙锁来搜索和扫描索引，默认值（为0）,间隙锁开启。
# 推荐用READ COMMITTED 替代他，这个变量不能设置为session级别。
| innodb_log_buffer_size | 16777216
#这个参数就是用来设置 Innodb 的 Log Buffer 大小的，系统默认值为 1MB。Log Buffer 的主要作用就是缓冲 Log 数据，提高写 Log 的 IO 性能。一般来说，如果你的系统不是写负载非常高且以 大事务居多的话，8MB 以内的大小就完全足够了。
#如果完全从 Log Buffer 本身来说，自然是大一些会减少更多的磁盘 IO。但是由于 Log 本身是 为了保护数据安全而产生的，而 Log 从 Buffer 到磁盘的刷新频率和控制数据安全一致的事务直接相关， 并且也有相关参数来控制（innodb_flush_log_at_trx_commit）.
| innodb_log_checksums | ON
| innodb_log_compressed_pages | ON
#指定重压缩页的位图是否存储到Innodb redo logs。这个变量在MySQL5.6.11新增的
| innodb_log_file_size | 1073741824 (Kb)
#在一个日志组中每一个日志文件大小。日志文件合并后的大小（(innodb_log_file_size *innodb_log_files_in_group）可以到达512G。默认是48M。值明智范围从1MB到缓冲池的大小的1/n，N是日志文件组中文件数。值越大，在缓冲池执行checkpoint 刷新活动次数越小，节省磁盘I/O。日志文件越大，崩溃恢复越慢。尽管在MySQL5.5改善了恢复的性能和使日志文件更少考虑。
| innodb_log_files_in_group | 2
#在日志组的日志文件数。
| innodb_log_group_home_dir | /data/mysql/
#在日志组的日志路径
| innodb_log_write_ahead_size | 8192
#全局动态变量，默认8192，即8K，范围：512bytes～innodb_page_size，以字节为单位。
表示redo log写前的块大小。InnoDB以512字节一个block的方式对齐写入ib_logfile文件，但文件系统一般以4096字节为一个block单位。如果即将写入的日志文件块不在OS Cache时，就需要将对应的4096字节的block读入内存，修改其中的512字节，然后再把该block写回磁盘。该参数解决这个问题，当当前写入文件的偏移量不能整除该值时，则补0，多写一部分数据。这样当写入的数据是以磁盘block size对齐时，就可以直接write磁盘，而无需read-modify-write这三步了。
| innodb_lru_scan_depth | 2000
#影响page cleaner线程一次扫描LRU/UNZIP_LRU的深度，默认为1024，IO有空余可以适当调大;
| innodb_max_dirty_pages_pct | 75.000000
关闭数据库之前，可以手工调整@@global.innodb_max_dirty_pages_pct为比较小的数值，然后等待dity pages变少，然后restart，可以减少启动要恢复的时间。
对于很大的innodb buffer的，设置小点的innodb_max_dirty_pages_pct理论上是比较合理的。谁见过在oracle数据库 中，v$bh.dirty占到90%的。反正dirty buffer writer是backgound async的，只要不要太lazy或者crazy就行。
| innodb_max_dirty_pages_pct_lwm | 0.000000
#防止在到达innodb_max_dirty_pages_pct时疯狂刷新，而是在达到这样一个限定值时，开始“优雅”的做刷新脏页（预刷新）。详细见函数af_get_pct_for_dirty
#mysql检查点事件受两个因素的制约：一个是amount,另外一个是age.amount主要由 innodb_max_dirty_pages_pct参数控制;至于age,主要是由日志文件大小有关。
| innodb_max_purge_lag | 0
#该变量控制 purge 操作滞后多长，才延迟INSERT,UPDATE和DELETE 操作。默认是0（不延迟）。
InnoDB 事务系统维护一个事务列表。它记录被UPDATE 和DELETE 操作标志为删除的记录。这个列表的长度
代表 purge_lag值。当purge_lag超过innodb_max_purge_lag，每个 INSERT, UPDATE, 和 DELETE 操作被延迟。延迟的数量是 ((purge_lag/innodb_max_purge_lag)*10)-5 毫秒。在极端情况下 purge_lag 巨大，以防止过度延迟。你可以设置一个延迟的时间上限通过 innodb_max_purge_lag_delay 配置选项，延迟是从开始清洗批次计算,每十秒。如果由于旧一致性读 读到要清除的行，不能运行清除，则操作不能延迟。
滞后的值显示在InnoDB监控输出的事务部分中的 history list length。例如,如果输出包括以下行,滞后值是20:History list length 20
| innodb_max_purge_lag_delay | 0
#指定最大延迟时间毫秒。任何非零值表示一个基于innodb_max_purge_lag值计算延迟时间的上限。默认为零意味着没有强制延迟间隔的上限。
| innodb_max_undo_log_size | 1073741824
#控制最大undo tablespace文件的大小，超过这个阀值时才会去尝试truncate. truncate后的大小默认为10M
| innodb_monitor_disable |
#关闭 INFORMATION_SCHEMA.INNODB_METRICS 表中一个或更多计数器。
| innodb_monitor_enable |
#打开 INFORMATION_SCHEMA.INNODB_METRICS 表中一个或更多计数器。
| innodb_monitor_reset |
#重置INFORMATION_SCHEMA.INNODB_METRICS 表中一个或更多计数器的值为0.
| innodb_monitor_reset_all |
#重置INFORMATION_SCHEMA.INNODB_METRICS 表中一个或更多计数器所有值（最小，最大，等待）
| innodb_old_blocks_pct | 37
#指定buffer pool用于旧块分表的百分比。范围从5到95。默认是37（即pool的3/8）.通常结合innodb_old_blocks_time一起使用
| innodb_old_blocks_time | 1000
#全局动态变量。5.6.6之后默认是1000，之前是0。单位是毫秒。
#该参数表示等到该时间后，再读取该页则会进入到new端，有效的避免了对于上述SQL对BP的污染。默认是0，单位是毫秒。如设置为1000则表示：读到该页到midpoint的位置，要再等1秒之后读取该页才能进入new列表。而0则表示读取到该页则会直接被放入到new列表。具体的可以看这里。和innodb_old_blocks_pct配合使用，该参数默认是37（3/8），即BP的3/8处。
BP(Buffer_pool)
| innodb_online_alter_log_max_size | 134217728
# #online ddl时并发DML产生的row log最大size，超过这个限制会导致DDL回滚 .
#对InnoDB表在Online DDL 操作，临时日志文件最大值。每个索引创建或修改表都有这个日志文件，这个日志文件存储在DDL操作期间对表插入，更新，删除的数据。当 innodb_sort_buffer_siz的值需要，临时日志文件自动扩展直到innodb_online_alter_log_max_size指定的值。如果任何临时日志文件超过这个上限,ALTER TABLE操作失败和所有未提交的并发DML操作被回滚。因此在ONLINE DDL 操作期间，有大量DML并发，应该增大该值。但也导致结束DDL操作需要更长时间当表被锁用来从日志应用数据。
| innodb_open_files | 2000
#这变量仅与你使用InnoDB多表空间文件有关，它指定MySQL在一时间保持打开.ibd 文件数。最小值是10，自从MySQL5.6.6默认值是300.
| innodb_optimize_fulltext_only | OFF
#改变OPTIMIZE TABLE语句操作Innodb表的方法，对含有全文索引的innodb表的维护操作期间，临时启用改变量。默认情况， OPTIMIZE TABLE 会对有聚集索引表进行重新整理数据。当启用这选项，OPTIMIZE TABLE跳过表数据重新整理，仅对有全文索引的新增，更新和删除的数据进行处理。
| innodb_page_cleaners | 1
全局变量， 5.7.7之前默认1，5.7.8之后默认4，范围：1～64
表示刷写BP脏页的线程数，5.6.2开始从master线程中独立出来，5.7.4开始支持多线程flush。这个值必须小于等于innodb_buffer_pool_instances。
| innodb_page_size | 16384
#如果使用SSD或是固态盘需要考虑：
#innodb_page_size = 4K
#Innodb_flush_neighbors = 0
# Innodb page size 可以选择 8K、 16K、 32K、 64K。不过因为Innodb每个page都有不小的冗余空间，从空间和内存利用的角度来讲，page size越大越好。但是从checkpoint的角度来讲恰恰相反，page size越小，性能越好
| innodb_print_all_deadlocks | ON
# #保存全部死锁信息
| innodb_purge_batch_size | 300
# 当开启独立线程清除undo 页时，表示一次删除多少个页，默认是20，不支持动态修改，一般不需要修改。
#控制每次full purge回收的undo页的数量
| innodb_purge_rseg_truncate_frequency | 128
#控制回收(收缩)undo log的频率.undo log空间在它的回滚段没有得到释放之前不会收缩，
想要增加释放回滚区间的频率,就得降低innodb_purge_rseg_truncate_frequency设定值。
| innodb_purge_threads | 4
# purge线程数，可以加快purge速度
#从InnoDB 1.2版本开始，InnoDB支持多个Purge Thread，这样做的目的是为了进一步加快undo页的回收。同时由于Purge Thread需要离散地读取undo页，这样也能更进一步利用磁盘的随机读取性能。如用户可以设置4个Purge Thread：
#而其目的是为了减轻原Master Thread的工作及对于用户查询线程的阻塞，进一步提高InnoDB存储引擎的性能。
| innodb_random_read_ahead | OFF
#InnoDB 提供了两种预读的方式，一种是 Linear read ahead，由参数innodb_read_ahead_threshold控制，当你连续读取一个 extent 的 threshold 个 page 的时候，会触发下一个 extent 64个page的预读。另外一种是Random read-ahead，由参数innodb_random_read_ahead控制，当你连续读取设定的数量的page后，会触发读取这个extent的剩余page。
| innodb_read_ahead_threshold | 56
#当顺序读取extent块（包含64个page) innodb_read_ahead_threshold 设置的page页数量时，触发一个异步读取请求，将下一个页提前读取到buffer_pool 中。 默认为56， 不支持动态修改，一般采用默认。
| innodb_read_io_threads | 4
# 控制后台线程处理数据页上的写请求， 默认是4，不支持动态修改，建议根据服务器的核数以及读写请求 的比例加以调整。
而在MySQL5.5.x中用2个innodb_read_io_threads和Innodb_write_io_threads取代此版本之前参数，
该参数值之和=2*cpu个数*cpu核数;如果你的系统读>写,可以设置innodb_read_io_threads值相对大点;反之，也可以.
| innodb_read_only | OFF
#启动server 在read-only模式。对于分布在数据库应用或者数据设置为只读介质。
也可以用于数据仓库共享相同的数据目录在多个实例之间。
| read_only | OFF
当read_only 系统变量启用时, server 不允许client 更新除了用户有超级权限, 默认这个变量是关闭的。
| innodb_replication_delay | 0
# 当innodb_thread_concurrency 线程已满时，Slave 端复制线程的延迟时间（ms), 默认为0， 不延迟，可动态修改。
| innodb_rollback_on_timeout | OFF
# 当查询因锁定等待错误而中断时，最后一条语句回滚了，整个事物还没有终止，如果将该选项设置为1，将会改变此行为。
#innodb_rollback_on_timeout是啥作用？
答：事务B在锁等待超时后是回滚事务内所有的statement还是最后一条语句；
0表示rollback最后一条语句，默认值；有点坑
1表示回滚事务B内所有的statements；
此参数是只读参数，需在my.cnf中配置，并且重启生效；
注意：回滚statements后不自动commit或rollback事务；坑
#总结：
1，关闭innodb_rollback_on_timeout后，一旦以begin;start transaction;等语句开启一个事务，当锁等待超时后，该事务请求的锁将不释放，直到事务提交或回滚或会话超时；
所以autocommit参数建议设置成ON，只要程序没有显示开启事务，就可以避免上述锁未释放问题。
2、开启innodb_rollback_on_timeout后，一旦锁等待超时，是事务内sql将全部回滚，且释放之前请求的锁。
3、当autocommit=on，只要不显示开启事务，将不存在上面2个问题，即锁的问题和回滚的问题
| innodb_rollback_segments | 128
# 由innodb_undo_logs 替代:
| innodb_sort_buffer_size | 27108864
#specifies the size of sort buffers used for sorting data during creation of an InnoDB index.
| innodb_spin_wait_delay | 6
#参数的值默认是6，可动态调整。
#为了防止自旋锁循环过快，耗费CPU，在MySQL5.5.X版本里引入了innodb_spin_wait_delay参数，作用是控制轮训间 隔，也就是说在每次轮训的过程中，会休息一会儿然后再轮训。
| innodb_stats_auto_recalc | ON
#对InnoDB表统计信息持久化时，表的row发生变化大于
10%(counter > n_rows / 10 /* 10%)并且innodb_stats_auto_recalc=on，统计信信息会更新（虽然innodb_stats_auto_recalc=on是自动重新计算，但是也是异步的，可能会延时，比如当瞬间的DML批量操作就可能有延时） 2.统计信息非持久化还是和5.5 一致的（表的row发生变化大于1/16时更新统计信息）
| innodb_stats_method | nulls_equal
#计算统计信息时，拥有相同key prefix的行算作一个value group(类似oracle索引中的num_distinct，其值越多意味着索引选择性越好)，average group size是非常重要的指标，即平均一个索引值返回的表行数，主要有两个用途：
1估算每次ref access要读取多少行
2 估算一个partial join要产生多少行 (…) join tab on tab.key = expr
由此可知，average group size越高则索引选择性越低，表基数即value group数量计算公式为N/S(N:表行数 S:average group size)，可通过show index查看
除了主键，索引不可避免的会遇到Null(对于<=>操作符，NULL和Non-null被同等对待，而Null = Null则会返回false)，mysql将NULL视作无穷小；
收集统计信息时，为了灵活的处理Null，InnoDB/MyISAM各引入一个参数Innodb_stats_method/myisam_stats_method，分别三个候选值：nulls_equal/nulls_unequal/nulls_ignored(其中innod_stats_method只有全局变量)
Nulls_equal：所有Null都相等，即算作一个value group；若Null过多则会导致average group size偏大
Nulls_unequal：所有Null互不相同，每个算作一个value group；如果non-null group size过大且null数量过多，此设置会拉低整体的average group size，可能导致滥用索引
Nulls_ignored：忽略Null
对于已经收集的统计信息，无法分辨其采用了那种方式；对于非InnoDB/MyISAM表，只有一种收集方式，即nulls_equal；
手工收集统计信息需要调用analyze table，但若表自上次analye至今没有任何改动，即便调用此命令实际也不会收集统计信息，需先让统计信息过期(插入一行再删除即可)
Mysql也可自动收集，诸如bulk insert/delete以及某些alter table语句均会触发
如何查看统计信息
Show index from table或查看information_schema.statistics表
Show table status或information_schema.tables表
| innodb_stats_on_metadata | OFF
#默认是关闭了这个会对INFORMATION_SCHEMA中的一些表进行查询操作，以方便索引统计信息，如果读要求高的建议关闭
#也就是说，当使用 SHOW INDEX, SHOW TABLE STATUS and SHOW [FULL] TABLES时，会自动更新统计信息，或者对应的从 INFORMATION_SCHEMA.TABLES和INFORMATION_SCHEMA.STATISTICS 表中查询时。
#实际上这个动态统计的功能已经不推荐了，以后增加参数控制 DML 期间也不作动态统计了。因此这个参数配置成 off 更合理些
| innodb_stats_persistent | ON
#优化器永久统计信息通过把统计信息保存在磁盘上，使得MySQL在选择语句的执行计划时，会选择相对一致的执行计划，提升了SQL执行计划的稳定性。
当开启innodb_stats_persistent=ON这个参数时或在建表时带了STATS_PERSISTENT=1参数，优化器的统计信息会永久保存到磁盘上。
| innodb_stats_persistent_sample_pages | 20
#每次采样的块数，默认为20
| innodb_stats_sample_pages | 8
#每次收集统计信息时采样的页数，默认为8
| innodb_stats_transient_sample_pages | 8
#默认为8个，取8个页块，分析结果作为统计信息
| innodb_status_output | OFF
| innodb_status_output_locks | OFF
# InnoDB各类监控输出结果
#仅在必要时开启，因为会造成性能开销，观察结束后切记关闭监控。若监控期间服务器重新启动，则监控不会自动开启，需删除原来的表并重建相关表，或者重新设置相关变量。表结构不重要，重要的是名字和需为InnoDB引擎。
#有四类InnoDB monitor：Standard Monitor、Lock Monitor、Tablespace Monitor、Table Monitor。其中Tablespace Monitor和Table Monitor将在后续版本（MySQL5.7中移除，对应的信息可从information_schema的表中获取）
Standard Monitor：监视活动事务持有的表锁、行锁；事务锁等待；线程信号量等待；文件IO请求；buffer pool统计信息；InnoDB主线程purge和change buffer merge活动。
Lock Monitor：提供额外的锁信息。
Tablespace Monitor：显示共享表空间中的文件段以及表空间数据结构配置验证。
Table Monitor：显示内部数据字典的内容。
# show engine innodb status\G; --显示更多关于监控信息，当打开后。
(root@(none)) Mysql >SET GLOBAL innodb_status_output=ON;
Query OK, 0 rows affected (0.00 sec)
(root@(none)) Mysql >SHOW variables like 'innodb_status_output';
+----------------------+-------+
| Variable_name | Value |
+----------------------+-------+
| innodb_status_output | ON |
+----------------------+-------+
1 row in set (0.00 sec)
(root@(none)) Mysql >show engine innodb status\G;
*************************** 1. row ***************************
Type: InnoDB
Name:
Status:
=====================================
2017-03-15 16:12:04 0x7fad2c2f5700 INNODB MONITOR OUTPUT
=====================================
| innodb_strict_mode | ON
#这个设置让MYSQL在某些条件下把告警改成抛错，尤其是无效的或者可能有风险的 create table 选项。 如果打开这个，就会检查 create table选项。
| innodb_support_xa | ON
# #innodb_support_xa 设置为1，标志支持分布式事物，主要保证binary log和其他引擎的主事务数据保持一致性，属于同步操作；如果你设置0，就是异步操作，这样就会一定程度上减少磁盘的刷新次数和磁盘的竞争
| innodb_sync_array_size | 1
#信号量等待队列最大长度
| innodb_sync_spin_loops | 30
#innodb_sync_spin_loops参数是自旋锁的轮转数，可以通过show engine innodb status来查看。相较于系统等待，自旋锁是低成本的等待；不过它是一个活跃的等待，会浪费一些cpu资源。因此如果看到大量的自旋等待和自旋轮转，则很显然它浪费了很多cpu资源。浪费cpu时间和无谓的上下文切换之间可以通过该值来平衡。
| innodb_table_locks | ON
#此变量定了innodb如何处理LOCK TABLES语句发出的表锁请求，默认（开启）立刻返回并且内部将表锁住。
当设置为0 时，他会接受lock table语句请求，但是直到所有锁释放后才从lock tables ... write返回。
| innodb_temp_data_file_path | ibtmp1:12M:autoextend
| innodb_thread_concurrency | 64
#InnoDB内核中同时可以允许最大的在线程数量（0表示没有限制），2*（CPU核数+磁盘数量）在理论上是一个合理的值，在实际应用中设置的更小一点可能会让性能更好一点。
#max_connections :
--允许服务器最大连接数，尽量不要设置很大。
MySQL数据库服务最大线程连接数参数max_connections，一般情况下都会设置在128-1024的范围，再结合实际业务可能的最大事务并发度，innodb_concurrency_tickets保持默认值一般情况下足够。
innodb_thread_concurrency = 0时(表示默然情况下，不限制线程并发执行数量），innodb_thread_sleep_delay参数就无效了。同样innodb_concurrency_tickets也没了意义，这里推荐设置innodb_thread_concurrency为0，这样可以更好地发挥CPU多核处理能力，提高并发量。
| innodb_thread_sleep_delay | 0
#线程首先睡眠innodb _thread_sleep_delay所规定的时间（微妙），然后再次尝试进入，如果还是不能进入，就会就进入一个等待队列并且把控制权限交给操作系统。
| innodb_tmpdir |
# tmpdir 目录
| innodb_undo_directory | /data/mysql/
#undo 目录
| innodb_undo_log_truncate | ON
#参数设置为1，即开启在线回收（收缩）undo log日志文件，支持动态设置。
| innodb_undo_logs | 128
#用于表示回滚段的个数（早期版本的命名为innodb_rollback_segments ），该变量可以动态调整，但是物理上的回滚段不会减少，只是会控制用到的回滚段的个数;
默认为128个回滚段
| innodb_undo_tablespaces | 0
#参数必须大于或等于2，即回收（收缩）一个undo log日志文件时，要保证另一个undo log是可用的。
#innoDB 设置独立UNDO 表空间：会有回滚操作
作为支持事务的存储引擎，必不可少， 设置独立undo 主要涉及2 个参数：
> 1 . innodb_undo_directory ：用于指定保存UNDO 日志的物理文件的位置。
> 2 . innodb_undo_tablespaces ： 用于指定 undo 表空间的数量，每个undo表空间都是一个独立的.idb文件。
此外， 还增加 innodb_undo_logs 的系统参数， 用于指定UNDO 表空间中回滚段的数量。（innodb_rollback_segments 为旧此相同功能参数，兼容以前版本）
undo 目前（5.6） 一旦创建，就不能删除，同时也不能降级到5.6 之前的版本。
| innodb_use_native_aio | ON
# 此项默认开启，推荐不改变。如果遇见操作系统异步I/O子系统的问题，阻止innodb启动，你可以将它关闭。
| innodb_version | 5.7.16
| innodb_write_io_threads | 4
+------------------------------------------+-----------------------------------------------------------------------------------------------
131 rows in set (0.00 sec)
498
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
