asdsInnoDB 是事务安全的MySQL 存储引擎，设计上采用了类似于Oracle 数据库的架构。通常来说， InnoDB 存储引擎是OLTP应用中核心表的首选存储引擎。同时，也正是因为InnoDB 的存在，才使MySQL 数据库变得更有魅力。本章将详细介绍InnoDB 存储引擎的体系架构及其不同于其他存储引擎的特性。
asdsadasdasdasdsadasdasdasdsadassdasdsadasdasdsadasdsadassadasdas————《MySQL技术内幕INNODB存储引擎》
InnoDB 存储引擎的关键特性插入缓存Insert BufferChange BufferInsert Buffer 的内部实现Merge Insert Buffer两次写自适应哈希索引异步IO刷新邻接页启动、关闭与恢复💖 感谢各位的暴击三连~💖
InnoDB 存储引擎的关键特性
sssassassassassassassassavssassassa①、插入缓存(Insert Buffer)
sssassassassassassassassavssassassa②、两次写(Double Write)
sssassassassassassassassavssassassa③、自适应哈希索引(Adaptive Hash Index)
sssassassassassassassassavssassassa④、异步IO (Async IO)
sssassassassassassassassavssassassa⑤、刷新邻接页(Flush Neighbor Page)
sdsssa注：这些特性为InnoDB 存储引擎带来更好的性能以及更高的可靠性。
插入缓存
Insert Buffer
sssaInsert Buffer可能是InnoDB 存储引擎关键特性中最令人激动与兴奋的一个功能。 lnnoDB 缓冲池中有Insert Buffer 信息固然不错，但是Insert Buffer 和数据页一样，也是物理页的一个组成部分。
sssa在InnoDB 存储引擎中，主键是行唯一的标识符。通常应用程序中行记录的插入顺序是按照主键递增的顺序进行插入的。因此，插入聚集索引(Primary Key) 一般是顺序的，不需要磁盘的随机读取。对于这类情况下的插入操作，速度是非常快的。
sdsssa注：并不是所有的主键插入都是顺序的。若主键类是UUID这样的类 （即通用唯一识别码 ，让分布式系统中的所有元素，都能有唯一的辨识信息），那么插入和辅助索引一样，同样是随机的。即使主键是自增类型，但是插入的是指定的值，而不是NULL 值，那么同样可能导致插入并非连续的情况。
sssa但是不可能每张表上只有一个聚集索引（主键），更多情况下，一张表上有多个非聚集的辅助索引(secondary index) 。比如，用户需要按照b 这个字段进行查找，并且b 这个字段不是唯一的：
CREATE TABLE t (a INT AUTO_ 工NCREMENT,b VARCHAR(30),PRIMARY KEY(a),key(b));
sssa在这样的情况下产生了一个非聚集的且不是唯一的索引。在进行插入操作时，数据页的存放还是按主键a 进行顺序存放的，但是对于非聚集索引叶子节点的插入不再是顺序的了，这时就需要离散地访问非聚集索引页，由于随机读取的存在而导致了插入操作性能下降（B+ 树的特性决定了非聚集索引插入的离散性）。
sssaInnoDB存储引擎开创性地设计了Insert Buffer（针对非聚集索引）：
sssdsa对于非聚集索引的插入或更新操作，不是每一次直接插入到索引页中，而是先判断插入的非聚集索引页是否在缓冲池中， 若在，则直接插入； 若不在，则先放入到一个 Insert Buffer 对象中，好似欺骗。
sdsssa注：数据库这个非聚集的索引已经插到叶子节点，而实际并没有，只是存放在另一个位置。然后再以一定的频率进行Insert Buffer 和辅助索引页子节点的merge (合并）操作，这时通常能将多个插入合并到一个操作中（因为在一个索引页中），这就大大提高了对于非聚集索引插入的性能。
sssssaInsert Buffer的使用需要同时满足以下两个条件：
ssdsdssdsdsdsdsdsdsdsssa①、索引是辅助索引;ssdssssa②、索引不是唯一的。
sdsssainsert Buffer带来的缺点：当应用程序进行大量的插入操作，这些都涉及了不唯一的非聚集索引， 也就是使用了Insert Buffer 。若此时MySQL 数据库发生了宕机，这时势必有大量的Insert Buffer并没有合并到实际的非聚集索引中去。因此这时恢复可能需要很长的时间，在极端情况下甚至需要几个小时。
sssa用户可以通过命令SHOW ENGINE INNODB STATUS来查看插入缓冲的信息：
mysql>SHOW ENGINE INNODB STATUS\G;*************************** 1. row***************************Type: InnoDBName :Status:100727 22 : 21 : 48 INNODB MONITOR OUTPUTPer second averages calculated from the last 44 seconds......---------------------------------------------------------INSERT BUFFER AND ADAPTIVE HASH INDEXIbuf: size 7545, free list len 3790, seg size 11336,8075308 inserts, 7540969 merged recs, 2246304 merges......---------------------------------------------------------END OF INNODB MONI TOR OUTPUT1 row in set (0.00 sec)
sssaseg size显示了当前Insert Buffer的大小为11336X 16KB, 大约为I77MB;free list len代表了空闲列表的长度；size代表了已经合并记录页的数量。Inserts代表了插入的记录数；merged recs代表了合并的插入记录数量；merges代表合并的次数，也就是实际读取页的次数。merges:merged recs 大约为1 : 3, 代表了插入缓冲将对于非聚集索引页的离散IO逻辑请求大约降低了2/3 。
sssssa目前Insert Buffer存在一个问题是：在写密集的情况下，插入缓冲会占用过多的缓冲池内存（innodb_buffer _pool）, 默认最大可以占用到1/2 的缓冲池内存。（后来可以通过，修改IBUF_POOL_SIZE_PER_MAX_SIZE就可以对插入缓冲的大小进行控制，比如值为3，就是1/3）。
Change Buffer
sssaInnoDB从1.0.x版本开始引入了Change Buffer, 可将其视为Insert Buffer 的升级。从这个版本开始，InnoDB存储引擎可以对DML操作（INSERT 、DELETE 、UPDATE）都进行缓冲 ：Insert Buffer 、Delete Buffer 、Purge buffer。
sdsssa注：当然和之前Insert Buffer一样，Change Buffer适用的对象依然是非唯一的辅助索引。
sssssaUPDATE操作可能分为两个过程：：
ssdsdssdsdsdsdsdsdsdsssa①、将记录标记为己删除；ssdssssa②、真正将记录删除。
sdsssa注：因此Delete Buffer对应UPDATE操作的第一个过程， 即将记录标记为删除。PurgeBuffer对应UPDATE操作的第二个过程，即将记录真正的删除。同时，InnoDB存储引擎提供了参数innodb_change_ buffering, 用来开启各种Buffer的选项。该参数可选的值为：inserts 、deletes 、purges 、changes 、all 、none 。inserts 、deletes 、purges 就是前面讨论过的三种情况。changes 表示启用inserts 和deletes , all 表示启用所有， none 表示都不启用。该参数默认值为all 。
sssa从InnoDB 1.2.x版本开始，可以通过参数innodb_change_ buffer_ max_ size来控制Change Buffer最大使用内存的数量。该参数值默认为25, 表示最多使用1/4的缓冲池内存空间。最大有效值为50。
sssa在MySQL5.5 版本中通过命令SHOW ENGINE INNODB STATUS, 可以观察到类似如下的内容：
mysql> SHOW ENGINE I NNODB STATUS\G;*************************** 1. row***************************Type: InnoDB----------------------------------------INSERT BUFFER AND ADAPTIVE HASH INDEX----------------------------------------Ibuf: size 1 , f ree list len 3 4397 , seg size 3 4399 , 10875 mergesmerged operations :insert 20462 , delete mark 8 , delete 4215discarded operat i ons :insert 0 , delete mark 0 , delete 0
sdsssa注：insert 表示Insert Buffer ; delete mark 表示Delete Buffer ; delete 表示Purge Buffer ; discarded operations 表示当 Change Buffer 发生 merge 时，表已经被删除，此时就无需再将记录合并(merge) 到辅助索引中了。
Insert Buffer 的内部实现
sssaInsert Buffer的数据结构是一棵B+ 树。在MySQL 4.1 之前的版本中每张表有一棵 Insert Buffer B+ 树。而在现在的版本中，全局只有一棵 Insert Buffer B+ 树，负责对所有的表的辅助索引进行Insert Buffer。而这棵 B+ 树存放在共享表空间中，默认也就是ibdatal中。因此，试图通过独立表空间ibd文件恢复表中数据时， 往往会导致CHECK TABLE失败。这是因为表的辅助索引中的数据可能还在Insert Buffer中，也就是共享表空间中，所以通过ibd文件进行恢复后，还需要进行REPAIR TABLE操作来重建表上所有的辅助索引。
sssaInsert Buffer是一棵B+树，因此其也由叶节点和非叶节点组成。非叶节点存放的是查询的search key(键值）。
sdsssa注：search key 一共占用9 个字节，其中space 表示待插入记录所在表的表空间id, 在InnoDB 存储引擎中，每个表有一个唯一的space id, 可以通过space id 查询得知是哪张表。space 占用4 字节。marker 占用1 字节，它是用来兼容老版本的Insert Buffer 。offset表示页所在的偏移量，占用4 字节。（也就是定位到了页）
sddssdsdsa<font face=“华文楷体”>当一个辅助索引要插入到页(space, offset) 时，如果这个页不在缓冲池中，那么 InnoDB 存储引擎首先根据上述规则构造一个search key, 接下来查询Insert Buffer 这棵 B+ 树，然后再将这条记录插入到Insert Buffer B+ 树的叶子节点中。
sssa对于插入到Insert Buffer B+树叶子节点的记录，并不是直接将待插入的记录插入，而是需要根据如下的规则进行构造：
sdsssa注：space 、marker 、offset字段和之前非叶节点中的含义相同，一共占用9 字节。第4 个字段metadata占用4 字节，其存储的内容如表。
sdsssaIBUF_REC_OFFSET_COUNT是保存两个字节的整数，用来排序每个记录进入Insert Buffer的顺序。因为从InnoDB l.0.x 开始支持Change Buffer, 所以这个值同样记录进入Change Buffer的顺序。通过这个顺序回放(replay) == 才能得到记录的正确值。从Insert Buffer叶子节点的第5 列开始，就是实际插入记录的各个字段了。因此较之原插入记录，Insert Buffer B+树的叶子节点记录需要额外13 字节的开销。
sssa因为启用Insert Buffer 索引后，辅助索引页(space, offect) 中的记录可能被插入到Insert Buffer B+树中，所以为了保证每次 Merge Insert Buffer 页必须成功，还需要有一个特殊的页用来标记每个辅助索引页 (space, page_no)的可用空间。这个页的类型为Insert Buffer Bitmap。
sssa每个Insert Buffer Bitmap页用来追踪16384个辅助索引页，也就是256 个区(Extent)（一个区64个辅助索引页） 。每个Insert Buffer Bitmap页都在16384 个页的第二个页中。
sssa每个辅助索引页在Insert Buffer Bitmap页中占用4位：
Merge Insert Buffer
sssa 问题1：Insert/Change Buffer是一棵B + 树。若需要实现插入记录的辅助索引页不在缓冲池中，那么需要将辅助索引记录首先插入到这棵B+树中。但是Insert Buffer 中的记录何时合并(merge ) 到真正的辅助索引中呢？
sssssaMerge Insert Buffer的操作可能发生在以下几种情况下：
ssdsdssdsdsdsdsdsdsdsssa①、辅助索引页被读取到缓冲池时；
ssdsdssdsdsdsdsdsdsdsssa②、Insert Buffer Bitmap 页追踪到该辅助索引页已无可用空间时；
ssdsdssdsdsdsdsdsdsdsssa③、Master Thread 。
sdsssa注1： 第一种情况为当辅助索引页被读取到缓冲池中时，例如这在执行正常的SELECT 查询操作，这时需要检查Insert Buffer Bitmap 页，然后确认该辅助索引页是否有记录存放于Insert Buffer B+ 树中。若有，则将Insert Buffer B+ 树中该页的记录插入到该辅助索引页中。可以看到对该页多次的记录操作通过一次操作合并到了原有的辅助索引页中，因此性能会有大幅提高。
sdsssa注2：Insert Buffer Bitmap页用来追踪每个辅助索引页的可用空间，并至少有1/32页的空间。若插入辅助索引记录时检测到插入记录后可用空间会小于1/32 页，则会强制进行一个合并操作，即强制读取辅助索引页，将Insert Buffer B+ 树中该页的记录及待插入的记录插入到辅助索引页中。
sdsssa注3：之前在分析Master Thread 时曾讲到，在Master Thread 线程中每秒或每10 秒会进行一次Merge Insert Buffer 的操作，不同之处在于每次进行merge 操作的页的数量不同。
sssa 问题 2：在 Master Thread 中，执行 merge 操作的不止是一个页，而是根据srv_ innodb io _capactiy的百分比来决定真正要合并多少个辅助索引页。但 InnoDB 存储引擎又是根据怎样的算法来得知需要合并的辅助索引页呢？
sssa在Insert Buffer B+ 树中，辅助索引页根据(space, offset) 都已排序好，故可以根据(space, offset) 的排序顺序进行页的选择。然而，对于Insert Buffer页的选择，InnoDB存储引擎并非采用这个方式，它随机地选择Insert Buffer B+ 树的一个页，读取该页中的space 及之后所需要数量的页。该算法在复杂情况下应有更好的公平性。同时，若进行merge 时，要进行merge 的表已经被删除，此时可以直接丢弃已经被 Insert/Change Buffer 的数据记录。
两次写
sssa 如果说Insert Buffer带给InnoDB存储引擎的是性能上的提升，那么doublewrite(两次写）带给InnoDB存储引擎的是数据页的可靠性。
sssa 问题：当发生数据库宕机时，可能InnoDB 存储引擎正在写入某个页到表中，而这个页只写了一部分，比如16KB 的页，只写了前4KB, 之后就发生了宕机，这种情况被称为部分写失效。
sdsssa解决方式1：通过重做日志进行恢复，但如果这个页本身已经发生了损坏，再对其进行重做是没有意义的
sdsssa解决方式2：对解决方式1进行改进，在应用(apply) 重做日志前，用户需要一个页的副本，当写入失效发生时，先通过页的副本来还原该页，再进行重做，这就是doublewrite。
sssssadoublewrite由两部分组成：
ssdsdssdsssssa①、内存中的doublewrite buffer, 大小为2MB
ssdsdssdsdsssa②、物理磁盘上共享表空间中连续的128 个页，即2个区(extent), 大小同样为2MB 。
ssssadoublewrite工作流程：
ssdsdssdsssssa①、在对缓冲池的脏页进行刷新时，并不直接写磁盘，而是会通过memcpy函数将脏页先复制到内存中的doublewrite buffer。
ssdsdssdsssssa②、之后通过doublewrite buffer再分两次，每次1MB 顺序地写入共享表空间的物理磁盘上，然后马上调用fsync函数，同步磁盘，避免缓冲写带来的问题。
sdsssa在这个过程中，因为doublewrite页是连续的，因此这个过程是顺序写的，开销并不是很大。在完成doublewrite页的写入后，再将 doublewrite buffer 中的页写入各个表空间文件中，此时的写入则是离散的。
sssa 可以通过以下命令观察到doublewrite运行的情况：
mysql>SHOW GLOBAL STATUS LIKE'innodb_dblwr 号' \ G ;*************************** 1 . row***************************Variable_narne : Innodb_ dblwr_pages_writtenValue : 6325194*************************** 2. row***************************Variable name: Innodb dblwr writesValue : 1003992 rows in set (0.00 sec )
sssadoublewrite一共写了6325194个页，但实际的写入次数为100399, 基本上符合64: 1。如果发现系统在高峰时的Innodb_ dblwrpageswritten : Innodb dblwr _writes远小于64: 1, 那么可以说明系统写入压力并不是很高（因为都通过二次写完成，并且没有类似宕机的事件发生）。如果操作系统在将页写入磁盘的过程中发生了崩溃，在恢复过程中， InnoDB 存储引擎可以从共享表空间中的doublewrite中找到该页的一个副本，将其复制到表空间文件，再应用重做日志。
sdsssa注1：若查看MySQL 官方手册，会发现在命令SHOW GLOBAL STATUS 中Innodb_buffer_pool_pages_ :flushed变星表示当前从缓冲池中刷新到磁盘页的数量。根据之前的介绍，用户应该了解到，在默认情况下所有页的刷新首先都需要放入到doublewrite 中，因此该变量应该和Innodb_dblwr_pages_written 一致。然而在MySQL 5 . 5.24 版本之前，Innodb_bufferpool_pages_flushed 总是为Innodbdblw _pages_written 的2倍，而此Bug直到MySQL5.5.24 才被修复。
sdsssa注2：参数skip_innodb doublewrite可以禁止使用doublewrite功能，这时可能会发生前面提及的写失效问题。不过如果用户有多个从服务器(slave server), 需要提供较快的性能（如在slaves erver 上做的是RAIDO), 也许启用这个参数是一个办法。不过对于需要提供数据高可靠性的主服务器(master server), 任何时候用户都应确保开启doublewrite 功能。
自适应哈希索引
sssa 哈希(hash) 是一种非常快的查找方法，在一般情况下这种查找的时间复杂度为0(1), 即一般仅需要一次查找就能定位数据。而B+ 树的查找次数，取决于 B+ 树的高度，在生产环境中， B+ 树的高度一般为3 ~ 4 层，故需要3~4 次的查询。
sssaInnoDB 存储引擎会监控对表上各索引页的查询。如果观察到建立哈希索引可以带来速度提升，则建立哈希索引，称之为自适应哈希索引(Adaptive Hash Index,AHI)。 AHI 是通过缓冲池的B+ 树页构造而来，因此建立的速度很快**，而且不需要对整张表构建哈希索引。InnoDB 存储引擎会自动根据访问的频率和模式来自动地为某些热点页建立哈希索引。
ssssa使用AHI的要求：
ssdsdssdsssssa①、对这个页的连续访问模式必须是一样的（指的是查询的条件一样），那么InonDB 存储引擎不会对该页构造AHI。
ssdsdssdsssssa②、以该模式至少访问了100 次
ssdsdssdsssssa③、页通过该模式访问了N 次，其中N= 页中记录*1/16
ssdsdssdsssssa④、哈希索引只能用来搜索等值的查询
sdsssa注1：根据InnoDB 存储引擎官方的文档显示，启用AHi 后，读取和写入速度可以提高2倍，辅助索引的连接操作性能可以提高5 倍。毫无疑问，AHi 是非常好的优化模式，其设计思想是数据库自优化的(self-tuning), 即无需OBA 对数据库进行人为调整。
sdsssa注2：通过命令SHOW ENGINE INNODB STATUS可以看到当前AHI的使用状况。可以通过参数innodb_adaptive_ hash_index禁用或启动此特性，默认AHI为开启状态。
异步IO
sssa哈希(hash) 为了提高磁盘操作性能，当前的数据库系统都采用异步IO(Asynchronous IO,AIO) 的方式来处理磁盘操作。InnoDB 存储引擎亦是如此。
sdsssa注：与AIO对应的是SyncIO, 即每进行一次IO 操作，需要等待此次操作结束才能继续接下来的操作。但是如果用户发出的是一条索引扫描的查询，那么这条SQL 查询语句可能需要扫描多个索引页，也就是需要进行多次的IO 操作。在每扫描一个页并等待其完成后再进行下一次的扫描，这是没有必要的。用户可以在发出一个IO 请求后立即再发出另一个 IO 请求，当全部 IO 请求发送完毕后，等待所有 IO 操作的完成，这就是AIO 。
sssaAIO的另一个优势：是可以进行IO Merge操作（比如要访问的页在一个表中并且紧挨着），也就是将多个IO合并为1 个IO, 这样可以提高IOPS（磁盘每秒的读写次数，用来衡量磁盘的性能)的性能。
sdsssa注1：在InnoDB l.l.x 之前， AIO 的实现通过InnoDB 存储引擎中的代码来模拟实现。而从 InnoDB 1.1.x 开始(InnoDB Plugin 不支持），提供了内核级别AIO 的支持，称为Native AIO 。因此在编译或者运行该版本MySQL 时，需要libaio 库的支持。若没有则会出现如下的提示：
/usr/local/mysql /bin/mysqld: error while l oading shared libraries: libaio.so.l:cannot open shared object file: No such file or directory
sdsssa注2：Windows 系统和Linux 系统都提供 Native AIO 支持，而Mac OSX 系统则未提供。因此在这些系统下，依旧只能使用原模拟的方式。参数innodb_use_ native_ aio用来控制是否启用Native AIO,在Linux 操作系统下，默认值为ON。用户可以通过开启和关闭Native AIO 功能来比较InnoDB 性能的提升。官方的测试显示，启用NativeAIO, 恢复速度可以提高75%。
sdsssa注3：在InnoDB 存储引擎中， read ahead 方式的读取都是通过AIO 完成，脏页的刷新，即磁盘的写入操作则全部由AIO 完成。
刷新邻接页
sssaInnoDB存储引擎还提供了Flush Neighbor Page( 刷新邻接页） 的特性。
sssa 工作原理为：当刷新一个脏页时，InnoDB 存储引擎会检测该页所在区(extent) 的所有页，如果是脏页，那么一起进行刷新。
sssa 好处：通过 AIO 可以将多个IO 写入操作合并为一个IO 操作，故该工作机制在传统机械磁盘下有着显著的优势。
ssssa刷新邻接页需要考虑的问题：
ssdsddsssa①、是不是可能将不怎么脏的页进行了写入，而该页之后又会很快变成脏页？
ssdssdsssa②、固态硬盘有着较高的IOPS, 是否还需要这个特性？
sssa 为此，InnoDB存储引擎从1.2 .x版本开始提供了参数innodb_flush_ neighbors, 用来控制是否启用该特性。对于传统机械硬盘建议启用该特性，而对于固态硬盘有着超高IOPS（磁盘每秒的读写次数，用来衡量磁盘性能的）性能的磁盘，则建议将该参数设置为O, 即关闭此特性。
启动、关闭与恢复
sssa InnoDB 是MySQL 数据库的存储引擎之一，因此InnoDB 存储引擎的启动和关闭，更准确的是指在MySQL 实例的启动过程中对InnoDB 存储引擎的处理过程。
sssa 在关闭时，参数innodb_fast_shutdown影响着表的存储引擎为InnoDB的行为。该参数可取值为0 、1 、2,默认值为1。
ssdsdssa①、0：表示在MySQL 数据库关闭时，InnoDB 需要完成所有的 full purge 和merge insert buffer, 并且将所有的脏页刷新回磁盘。这需要一些时间，有时甚至需要几个小时来完成。如果在进行InnoDB 升级时，必须将这个参数调为0, 然后再关闭数据库。
ssdsdssa②、1：是参数innodb_ fast_ shutdown的默认值，表示不需要完成上述的full purge 和merge insert buffer 操作，但是在缓冲池中的一些数据脏页还是会刷新回磁盘。
ssdsds sa③、2：表示不完成 full purge 和merge insert buffer 操作，也不将缓冲池中的数据脏页写回磁盘，只是将日志都写入日志文件。这样不会有任何事务的丢失，但是下次 MySQL 数据库启动时，会进行恢复操作 。
sdsssa注：当正常关闭MySQL数据库时，下次的启动应该会非常“正常＂。但是如果没有正常地关闭数据库，如用kill命令关闭数据库，在MySQL数据库运行中重启了服务器，或者在关闭数据库时，将参数innodb_ fast_ shutdown设为了2时，下次MySQL数据库启动时都会对InnoDB 存储引擎的表进行恢复操作。
sdsssa参数innodb_force_recovery：影响了整个InnoDB存储引擎恢复的状况。该参数值默认为0, 代表当发生需要恢复时，进行所有的恢复操作， 当不能进行有效恢复时，如数据页发生了corruption,MySQL数据库可能发生宕机(crash), 并把错误写入错误日志中去。
sdsssa注：但是，在某些情况下，可能并不需要进行完整的恢复操作，因为用户自已知道怎么进行恢复。比如在对一个表进行alter table操作时发生意外了，数据库重启时会对InnoDB表进行回滚操作，对于一个大表来说这需要很长时间，可能是几个小时。这时用户可以自行进行恢复，如可以把表删除，从备份中重新导入数据到表，可能这些操作的速度要远远快于回滚操作。
ssds参数innodb_force_ recovery可以设置为6 个非零值： 1~6 。
ssdssa①、1 (SRV FORCE_IGNORE_CORRUPT): 忽略检查到的corrupt页。
ssdssa②、2(SRV_FORCE_NO—BACKGROUND):阻止Master Thread 线程的运行，如Master Thread 线程需要进行 full purge 操作，而这会导致crash 。
ssdssa③、3(SRV_FORCE_NO_TRX_UNDO):不进行事务的回滚操作。
ssdssa④、4(SRV FORCE—NO_IBUF MERGE): 不进行插入缓冲的合并操作。
ssdssa⑤、5(SRV FORCE_NO_UNDO_LOG_SCAN): 不查看撤销日志(Undo Log),InnoDB存储引擎会将未提交的事务视为己提交。
ssdssa⑥、6(SRV FORCE_NO_LOG_REDO):不进行前滚（前滚：将未完成的操作继续完成,）的操作。
sdsssa注：在设置了参数innodb_ force_recovery大于0后，用户可以对表进行select 、create 和drop 操作，但insert 、update 和delete 这类DML 操作是不允许的。
