本节摘取了mysql5.6.23的几个和innodb相关的主要bugfix，简单阐述下问题及解决方案。
<b>问题一</b>
当执行flush table..for export命令时，会暂停purge线程的操作。这一步通过设置一个标记purge_sys->state的值为purge_state_stop来告诉purge线程该停下来歇歇了。
然而如果purge线程当前正在函数srv_do_purge中工作，该函数会执行一个while循环，退出条件是当前server shutdown，或者上次purge的page数为0，并没有检查purge线程的状态是否被设置为purge_state_stop; 很显然，如果当前的history list非常长，那么可能需要等待purge完成后，才能退出循环，而在用户看来，就好像hang了很久一样。推长history list 很容易：开启一个打开read view的事务（例如rr级别下执行一个select）不做提交，同时有并发的dml，跑一段时间history list就上去了。
<b>解决</b>
在函数srv_do_purge函数的while退出条件中加上purge线程状态判断，如果被设置为purge_state_stop，就退出循环。
<a href="https://github.com/mysql/mysql-server/commit/f9a1df899b724d26d7997a49e6403bbe90024bf3">补丁</a>
<b>问题二</b>
在执行innodb crash recovery阶段，如果发现不合法的大字段，就会去调用函数ib_warn_row_too_big 去打印一条warning，函数为push_warning_printf。然而这个函数的目的是给客户端返回一条warning，而这时候系统还在崩溃恢复阶段，并没有合法的thd对象，因此造成系统崩溃。
tips：这个bug是在升级到新版本5.6出现的，最根本的原因是5.6新版本对大字段长度做的约束。早期版本5.6及之前的版本，我们可以定义非常大的blob字段，但如果字段太长，对这些字段的修改，可能导致redo log的checkpoint点被覆盖，因为计算redo log 空间是否足够，并没有依赖即将插入的redo 记录长度，而仅仅是保留一定的比例。因此在5.6.22版本中做了限制：如果blob的长度超过innodb_log_file_size * innodb_log_files_in_group的十分之一时，就会更新失败，给用户返回db_too_big_record的错误码。这个问题在5.7版本里被彻底解决：每写4个blob外部存储页，检查一次redo log空间是否足够，如果不够用，就推进checkpoint点。
在函数ib_warn_row_too_big中判断当前线程thd是否被初始化，如果为null，直接返回，不调用push_warning_printf。
<a href="https://github.com/mysql/mysql-server/commit/901ce5314b6b0d4115b0237491e2afaafe5a274e">补丁</a>
<b>问题三</b>
当我们通过alter语句修改一个被外键约束的列名时，由于没有从数据词典cache中将包含老列名的cache项驱逐掉，导致重载外键约束时失败。
举个简单的例子：
可以看到，尽管t1表的a列已经被rename成 id，但打印出来的信息也并没有更正。
当被外键约束的列名被修改时，将对应的外键项从数据词典cache中驱逐，当其被随后重新加载时就会使用新的对象。
<a href="https://github.com/mysql/mysql-server/commit/a54364d2d1c147d6c325c818057de470672f8e3d">补丁</a>
<b>问题四</b>
如上文所提到的，在新版本innodb中，对blob字段的数据操作需要保证其不超过总的redo log file大小的十分之一，但是返回的错误码db_too_big_record及打印的信息太容易让人误解，大概如下：
输出更合适、更直观的错误信息，如下：
<a href="https://github.com/mysql/mysql-server/commit/4423b9b5633d91e5793ee637ac068059001f85ba">补丁</a>
<b>问题五</b>
flush table操作在某些情况下可能导致实例crash。 例如如下执行序列：
当执行flush table时，在重载表cache时，innodb层会针对每个表设置其状态（ha_innobase::store_lock）。如果执行flush 操作，并且加的是读锁时，就会调用函数row_quiesce_set_state将table->quiesce设置为quiesce_start。在上例中，表t1的两个表名表均加读锁，造成重复设置状态为quiesce_start，导致断言失败。
tips：在5.6版本中，虽然有明确的flush table..for export命令来协助转储ibd文件。但实际上，简单的flush table操作默认就会产生一个tbname.cfg的配置文件，拷贝该文件和ibd，可以将数据转移到其他实例上。table->quiesce用于标识操作状态，例如，如果标识为quiesce_start，就会在函数ha_innobase::external_lock中调用row_quiesce_table_start来启动配置文件的生成。
移除断言
<a href="https://github.com/mysql/mysql-server/commit/a3f3c2ab7a1b985775f4e58529a4dd563c025b8e">补丁</a>
<b>问题六</b>
线上实例错误日志中偶尔出现 “unable to purge a record”，从官方bug系统来看，很多用户都遇到了类似的问题。
当change buffer模块以如下序列来缓存索引操作时可能产生上述错误信息：
记录被标记删除（ibuf_op_delete_mark）
随后插入相同记录--ibuf_op_insert
purge线程需要物理删除二级索引记录，操作被buffer--ibuf_op_delete
当读入物理页时，总是需要进行ibuf merge。如果执行到ibuf_op_delete这种类型的change buffer时，发现记录并没有被标记删除，就会导致错误日志报错。
显然上述的操作序列是不合理的，正确的序列应该是ibuf_op_delete_mark，ibuf_op_delete，ibuf_op_insert。
为了搞清楚逻辑，我们简单的理一下相关代码。
注意ibuf_op_delete是由第一步的标记删除操作触发，purge线程发起；在每个buffer pool的控制结构体中，有一个成员buf_pool->watch[buf_pool_watch_size]，buf_pool_watch_size的值为purge线程个数，用于辅助purge操作。
假定内存中没有对应的page，purge线程会做如下几件事儿：
首先查询buffer pool，看看page是否已经读入内存；如果不在内存中，则将page no等信息存储到watch数组中，并插入page hash（buf_pool_watch_set）。（如果随后page被读入内存，也会删除watch标记）
判断该二级索引记录是否可以被purge（row_purge_poss_sec，当该二级索引记录对应的聚集索引记录没有delete mark并且其trx id比当前的purge view还旧时，不可以做purge操作）
随后在插入ibuf_op_delete类型的ibuf记录时，还会double check下该page是否被设为sentinel （ibuf_insert_low，buf_pool_watch_occurred），如果未被设置，表明已经page已经读入内存，就可以直接去做purge，而无需缓存了。
对于普通的操作类型，例如ibuf_op_insert和ibuf_op_delete_mark，同样也会double check page 是否读入了内存。在函数ibuf_insert中会调用buf_page_hash_get进行检查，如果page被读入内存，则不缓存操作，如果请求的page被设为sentinel，则从buf_page_hash_get返回null，因此随后判定需要缓存该类型的操作。这也正是问题的所在：
标记删除记录，写入ibuf_op_delete_mark
purge线程设置page对应的sentinel，完成合法性检查，准备调用ibuf_insert
插入相同记录，写入ibuf_op_insert
purge线程写入ibuf_op_delete
如果记录所在的page被设置了一个sentinel，那么对该page的并发插入操作就不应该缓存到change buffer中，而是直接去尝试读取物理页。
<a href="https://github.com/mysql/mysql-server/commit/ec369cb4f363161dfbbbd662b20763b54808b7d1">补丁</a>
<b>问题七</b>
对于非windows系统的平台上，函数os_file_pwrite和os_file_pread在碰到io错误时返回-1，并错误的作为写入/读取的字节数写在错误日志中。
单独记录失败的系统调用日志，打印更可读的日志信息。
<a href="https://github.com/mysql/mysql-server/commit/ae0f4c17c82d1d3ee89ca5afb64655b4ab1d2552">补丁</a>
<b>问题八</b>
在崩溃恢复后立刻执行一次slow shutdown （innodb_fast_shutdown = 0） 可能产生断言失败crash。原因是当完成crash recovery后，对于需要回滚的事务，会起单独的线程来执行，这时候如果shutdown实例，会触发触发purge线程内部断言失败：ut_a(n_pages_purged == 0 || srv_fast_shutdown != 0);
等待trx_rollback_or_clean_all_recovered完成后，再进行slow shutdown
<a href="https://github.com/mysql/mysql-server/commit/8edcc65fcd0c930a902cdf1c41ad0a1aaf21ff90">补丁</a>
![2021-08-08 mysql索引[图]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)