mysql游标使用中的一些推断

mysql游标使用过程中，坑太多，只能一步一步摸索，在一个存储中，定义了多个游标，用于数据校验，一般都会定义

DECLARE CONTINUE HANDLER FOR SQLSTATE '02000' SET done = 1,done1 = 1,done2 = 1;
或
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done=1;

现有这么一个场景，先从表中查询定义多个游标，然后遍历游标，更新表中未在游标中的字段，当第一个游标遍历完成后，后面的游标都失效了，即fetch时拿不到值了，通过和其它场景对比，推测如下：

①定义多个游标，用来遍历，在其它的表上进行insert，update,对定义的游标无影响，第一次游标遍历结束后，遍历第二个游标时，设置：

set done = 1 即可。

②如果还在本表上进行insert、update，那么其它的游标将失效，游标未打开时，进行insert或update并不造成影响，一旦一个游标打开，遍历，当结束时，其余游标失效。

此种情况下，即使在同一个存储中定义多个begin...end块，并未起作用。

一种思路如下：

可存储拆分，定义多个存储过程，每个里面定义一个游标，处理对应的逻辑，然后将多个存储按顺序依次调用。

mysql的存储调试比较麻烦，不好加断点进行debug，dbforge studio for mysql 这个工具值得一试。

编写mysql存储时，采用 navicate，校验比较弱，有些错误校验不出来，但执行时，只要一条出错，之后整个的过程都会出现比较诡异的结果，if判断无法正常进行，程序会一条一条执行，即使是查询，也查不出对应的结果，给程序调试带来难度。

情景一：

-- 按顺序定义
DECLARE done INT DEFAULT 0;
DECLARE done1 INT DEFAULT 0;
DECLARE done2 INT DEFAULT 0;
DECLARE cur1 CURSOR FOR SELECT serid,seqnum,col2 from tbl_base_import where serid = in_batchid and seqnum > 2;
DECLARE cur2 CURSOR FOR SELECT i.serid,i.seqnum,i.col7 from tbl_base_import i where i.serid = in_batchid and i.seqnum > 2;
DECLARE CONTINUE HANDLER FOR SQLSTATE '02000' SET done