1093的问题,是在于为了避免修改数据导致子查询匹配问题,如果确实有需求,一般推荐是先查询出来数据,然后另外执行修改.

对于你说的gdb跳过错误,不确定你指的是那部分代码?

对于mysql来说,只有事务提交的时候,同一时间只能有一个session写入binlog,直到这个session写完并释放写入锁.

因此binlog里面,每个事务必然是连续的(按照事务内执行顺序),事务之间的顺序,如果都在等写入锁,那么会有个抢锁的过程,谁抢到就是谁下一个写入binlog.

1.你是说在子查询的执行过程中，其他session数据修改导致数据偏差的问题吗？但是这里子查询是share锁，通过测试innodb的rc和rr两种事务级别都没造成功测试案例！能否有相关案例提供学习一下！

2.gdb跳过错误是指检验dml语句子查询是否包含本身时候，set 变量 让程序继续执行，而不报错误！

3.另外insert…select语句是不限制的，通过gdb去修改程序执行逻辑之后，死循环一直插入，所以也怀疑是不是为了防止递归？

补充说明一下:

网上说的原因是session1执行dml语句时候，如果这时候session2也去修改这个表的记录然后session2先执行结束先提交，会导致可能主库修改了2条记录但是从库可能执行了3条语句！但是测试myisam和innodb的rc和rr事务级别都没有发现session2的commit先提交！(可能自己测试样例的数据设置不合理)

先说MyISAM和InnoDB的问题.

这个"网上"的说法本身就是错误的,所以必然无法复现.

MyISAM是非事务存储引擎,每次写入都会有表级别的排他锁,不会涉及这些可见性问题,而InnoDB是事务存储引擎,读未提交以上的隔离级别下也必然会保证隔离性,前文我已经说过,提交写binlog事务是完整的,不会有这种两个事务在从库交叉执行的问题(包括并行复制在内,都会错开这种形式的交叉执行)

1093的详细处理:

1. 建表create table rex (id int primary key,c varchar(123));

2. update rex set c=2 where id in (select id from rex);  这个语句必然触发1093

3. 如果想要执行成功,update rex set c=2 where id in (select * from (select id from rex) x)这条可以执行成功

4. 这里涉及的问题是,对于步骤2的例子,mysql实际执行的时候,特定情况下,如果有一行匹配到子查询内的条件,但修改之后,是不匹配子查询内条件的,这里会有可能有逻辑判断的问题.mysql对update这里做了单独的判断,但仅处理一层子查询,如果类似步骤3的写法,可以避开这个判断,但是,特定情况下,修改可能会不符合预期.

另外,你一直提到gdb断点,你set的变量具体是哪个?数据库本身是一个完整的体系,贸然变更内部的运行中变量会导致运行异常,一般建议采用gdb追踪而非破坏性的变量变更学习源代码

如果依然不清楚,建议留下联系方式,我们电话沟通,更方便些.