诊所网站模板,二手交易平台 网站开发,html5游戏开发,淄博网站优化推广源码分析丨MySQL的多层SP中Cursor相关BUG 一、问题发现 在一次开发中在sp中使用多层cursor的时候想知道每层的m_max_cursor_index值分别是多少#xff0c;以用来做后续开发。于是做了以下的试验#xff0c;但是发现第一个level2那层的m_max_cursor_index的值有点问题。 注以用来做后续开发。于是做了以下的试验但是发现第一个level2那层的m_max_cursor_index的值有点问题。 注本次使用的MySQL数据库版本为最新的debug版本。 SQL语句示例 greatsql CREATE TABLE t1 (a INT, b VARCHAR(10));以下注释里面是该层sp_pcontext的参数值。 DELIMITER $$ CREATE PROCEDURE processnames() -- level0m_max_cursor_index181 BEGINDECLARE nameCursor0 CURSOR FOR SELECT * FROM t1; -- level1m_cursor_offset0m_max_cursor_index181beginDECLARE nameCursor1 CURSOR FOR SELECT * FROM t1; -- level2m_cursor_offset1m_max_cursor_index18 ☆问题点beginDECLARE nameCursor2 CURSOR FOR SELECT * FROM t1; -- level3m_cursor_offset2m_max_cursor_index1DECLARE nameCursor3 CURSOR FOR SELECT * FROM t1; -- level3m_cursor_offset2m_max_cursor_index2DECLARE nameCursor4 CURSOR FOR SELECT * FROM t1; -- level3m_cursor_offset2m_max_cursor_index3DECLARE nameCursor5 CURSOR FOR SELECT * FROM t1; -- level3m_cursor_offset2m_max_cursor_index4end;end;beginDECLARE nameCursor6 CURSOR FOR SELECT * FROM t1; -- level2m_cursor_offset1m_max_cursor_index1end; END $$ DELIMITER ; 首先查看上面的sp的code可以发现nameCursor6和nameCursor1属于同一层因此他们的offset值一样。 greatsql show procedure code processnames; -------------------------------------------- | Pos | Instruction | -------------------------------------------- | 0 | cpush nameCursor00: SELECT * FROM t1 | | 1 | cpush nameCursor11: SELECT * FROM t1 | | 2 | cpush nameCursor22: SELECT * FROM t1 | | 3 | cpush nameCursor33: SELECT * FROM t1 | | 4 | cpush nameCursor44: SELECT * FROM t1 | | 5 | cpush nameCursor55: SELECT * FROM t1 | | 6 | cpop 4 | | 7 | cpop 1 | | 8 | cpush nameCursor61: SELECT * FROM t1 | | 9 | cpop 1 | | 10 | cpop 1 | -------------------------------------------- 11 rows in set (6.02 sec) 然后通过debug查看每层sp_pcontext的参数值相关参数值已经在上面标识出发现第一个level2的sp_pcontext的m_max_cursor_index值多了很多预期值应该是41但是实际是81而上面的层都没错这说明代码最里面那层m_max_cursor_index赋值错了。 二、问题调查过程 1、发现了问题点就看看代码里面对于每层的m_max_cursor_index是怎么赋值的。 1、初始化sp_pcontext的时候所有的参数都为0 sp_pcontext::sp_pcontext(THD *thd) : m_level(0),m_max_var_index(0),m_max_cursor_index(0)...{init(0, 0, 0, 0);}2、每加一层sp_pcontext当前的m_cursor_offset上一层cursor个数 sp_pcontext::sp_pcontext(THD *thd, sp_pcontext *prev, sp_pcontext::enum_scope scope): m_level(prev-m_level 1),m_max_var_index(0),m_max_cursor_index(0)... {init(prev-current_cursor_count());} void sp_pcontext::init(uint cursor_offset) {m_cursor_offset cursor_offset;} uint current_cursor_count() const {return m_cursor_offset static_castuint(m_cursors.size()); }3、退出当前sp_pcontext层需要把当前的max_cursor_index()信息值赋值给上一层的m_max_cursor_index即当前的cursor数量累加给上一层 sp_pcontext *sp_pcontext::pop_context() {uint submax max_cursor_index();if (submax m_parent-m_max_cursor_index)m_parent-m_max_cursor_index submax; } uint max_cursor_index() const {return m_max_cursor_index static_castuint(m_cursors.size());}4、每次增加一个cursorm_max_cursor_index值递增m_max_cursor_index是计数器。 bool sp_pcontext::add_cursor(LEX_STRING name) {if (m_cursors.size() m_max_cursor_index) m_max_cursor_index;return m_cursors.push_back(name); } 2、根据第一步的分析只在最里面那层的m_max_cursor_index累加出来计算错误看看上面的累加过程是用max_cursor_index()值来累加的于是查看max_cursor_index()函数的实现 uint max_cursor_index() const {return m_max_cursor_index static_castuint(m_cursors.size());} 这里是把当前层的m_max_cursor_index值加上m_cursors.size()但是在函数add_cursor里面m_cursors数组每增加一个cursorm_max_cursor_index都要加1也就是说在最里面那层sp_pcontext的计算重复了计算了2遍m_cursors.size()导致上面的level2那层的m_max_cursor_index值变成2*48了。到这里问题点发现。 三、问题解决方案 通过以上代码解析后可以考虑只对最里面那层sp_pcontext的max_cursor_index()取值进行修改最里面那层的sp_pcontext没有m_children因此可以用这个数组值进行判断。代码作如下修改 uint max_cursor_index() const {if(m_children.size() 0) -- 最里面那层sp_pcontext直接返回m_max_cursor_index的值。return m_max_cursor_index; -- 可以改为static_castuint(m_cursors.size())二者值一样。else -- 上层sp_pcontext返回下层所有sp_pcontext的m_max_cursor_index的值再加上当前层的m_cursors.size()值。return m_max_cursor_index static_castuint(m_cursors.size()); } 四、问题总结 在MySQL的sp里面使用cursor的话因为m_max_cursor_index只用于统计不用于实际赋值和计算过程因此不影响使用。但是如果要用这个值用于二次开发就要注意到这个问题。上面的修改方案只是其中一个解决方案也可以根据自己的需要去改add_cursor的m_max_cursor_index的赋值过程。 这次发现的问题属于不参与计算的bug但却影响开源代码的后续开发在实际开发应用中类似的问题也要注意一不小心就会踩坑。 Enjoy GreatSQL :) 关于 GreatSQL GreatSQL是适用于金融级应用的国内自主开源数据库具备高性能、高可靠、高易用性、高安全等多个核心特性可以作为MySQL或Percona Server的可选替换用于线上生产环境且完全免费并兼容MySQL或Percona Server。 相关链接 GreatSQL社区 Gitee GitHub Bilibili GreatSQL社区 社区有奖建议反馈 https://greatsql.cn/thread-54-1-1.html 社区博客有奖征稿详情 https://greatsql.cn/thread-100-1-1.html 对文章有疑问或者有独到见解都可以去社区官网提出或分享哦~ 技术交流群 微信QQ群 QQ群533341697 微信群添加GreatSQL社区助手微信号wanlidbc 好友待社区助手拉您进群。