-
编辑 删除
MySQL：MTS和mysqldump死锁
一、问题来源这是一位客户的提供的案例如下，show processlist截图如下： 出现这种问题除非手动干预，杀掉FTWRL的session主从方可以进行。版本社区版5.7.26 二、堵塞图如果分析上面的堵塞可以画图如下： 三、关于woker线程w1和w3的等待这里我们需要重点关注参数slave_preserve_commit_order，在我将要出版的《深入理解MySQL主从原理》一
-
编辑 删除
MySQL：Innodb purge线程略解
水平有限，如有错误请谅解。源码版本8.0.21。 在处理一个故障的时候怀疑大量的删除数据导致了查询比较慢，但是自己对purge线程的工作流程一直不太清楚，本文不做深入解析，只做工作流程解析，带着如下问题进行： del flag记录是否能够及时清理为什么History list length持续不为0，是否代表del flag记录没有清理purge线程触发的规则是什么 一、purg
-
编辑 删除
MySQL 5.7：desc order by反向定位
定位模式为PAGE_CUR_L，反向定位,想定位到最后一行然后使用handler::ha_index_prev扫描上一行。但是5.7的代价比8.0的逆序索引高。 0x4e 0x20 为20000 mysql> desc select * from sortdescpart1 where a1=4 and a2>100 and a2
-
编辑 删除
MySQL:AHI 部分代码流程说明
AHI实际上就是多个hash查找表，个数由innodb_adaptive_hash_index_parts进行控制其中的建为记录本生计算的，值为rec指针。ha_node_set_data(node, block, data);如果开启debug会记录block这个属性。注意insert如果进行大量的插入，需要大量的定位操作，而不是一次定位顺序访问。及btr_cur_search_to_nth_l
-
编辑 删除
MySQL：从一个案例深入剖析InnoDB隐式锁和可见性判断
一、问题抛出最近遇到一个问题，得到栈如下（5.6.25）： 出现这个问题的时候只存在一个读写事务，那就是本事务。对这里的红色部分比较感兴趣，但是这里不是所有的内容都和这个问题相关，主要还是围绕可见性判断和隐式锁判定进行，算是我的思考过程。但是对Innodb认知水平有限，如有误导请谅解。使用的源码版本5.7.29。 二、read view 简述关于read view说明的文章已经很多了，我这
