翼度科技»论坛 编程开发 mysql 查看内容

MySQL的多层SP中Cursor的m_max_cursor_index相关BUG分析

6

主题

6

帖子

18

积分

新手上路

Rank: 1

积分
18
源码分析丨MySQL的多层SP中Cursor相关BUG

一、问题发现

在一次开发中在sp中使用多层cursor的时候想知道每层的m_max_cursor_index值分别是多少,以用来做后续开发。于是做了以下的试验,但是发现第一个level=2那层的m_max_cursor_index的值有点问题。
注:本次使用的MySQL数据库版本为最新的debug版本。
SQL语句示例:
  1. greatsql> CREATE TABLE t1 (a INT, b VARCHAR(10));
  2. 以下注释里面是该层sp_pcontext的参数值。
  3. DELIMITER $$
  4. CREATE PROCEDURE processnames() -- level=0,m_max_cursor_index=1+8+1
  5. BEGIN
  6.     DECLARE nameCursor0 CURSOR FOR SELECT * FROM t1; -- level=1,m_cursor_offset=0,m_max_cursor_index=1+8+1
  7.     begin
  8.            DECLARE nameCursor1 CURSOR FOR SELECT * FROM t1; -- level=2,m_cursor_offset=1,m_max_cursor_index=1+8 ☆问题点
  9.        begin
  10.                         DECLARE nameCursor2 CURSOR FOR SELECT * FROM t1; -- level=3,m_cursor_offset=2,m_max_cursor_index=1
  11.             DECLARE nameCursor3 CURSOR FOR SELECT * FROM t1; -- level=3,m_cursor_offset=2,m_max_cursor_index=2
  12.             DECLARE nameCursor4 CURSOR FOR SELECT * FROM t1; -- level=3,m_cursor_offset=2,m_max_cursor_index=3
  13.             DECLARE nameCursor5 CURSOR FOR SELECT * FROM t1; -- level=3,m_cursor_offset=2,m_max_cursor_index=4
  14.         end;
  15.            end;
  16.     begin
  17.                 DECLARE nameCursor6 CURSOR FOR SELECT * FROM t1; -- level=2,m_cursor_offset=1,m_max_cursor_index=1
  18.            end;
  19. END $$
  20. DELIMITER ;
复制代码
首先查看上面的sp的code,可以发现nameCursor6和nameCursor1属于同一层,因此他们的offset值一样。
  1. greatsql>  show procedure code processnames;
  2. +-----+---------------------------------------+
  3. | Pos | Instruction                           |
  4. +-----+---------------------------------------+
  5. |   0 | cpush nameCursor0@0: SELECT * FROM t1 |
  6. |   1 | cpush nameCursor1@1: SELECT * FROM t1 |
  7. |   2 | cpush nameCursor2@2: SELECT * FROM t1 |
  8. |   3 | cpush nameCursor3@3: SELECT * FROM t1 |
  9. |   4 | cpush nameCursor4@4: SELECT * FROM t1 |
  10. |   5 | cpush nameCursor5@5: SELECT * FROM t1 |
  11. |   6 | cpop 4                                |
  12. |   7 | cpop 1                                |
  13. |   8 | cpush nameCursor6@1: SELECT * FROM t1 |
  14. |   9 | cpop 1                                |
  15. |  10 | cpop 1                                |
  16. +-----+---------------------------------------+
  17. 11 rows in set (6.02 sec)
复制代码
然后通过debug查看每层sp_pcontext的参数值(相关参数值已经在上面标识出),发现第一个level=2的sp_pcontext的m_max_cursor_index值多了很多,预期值应该是4+1,但是实际是8+1,而上面的层都没错,这说明代码最里面那层m_max_cursor_index赋值错了。
二、问题调查过程

1、发现了问题点就看看代码里面对于每层的m_max_cursor_index是怎么赋值的。
  1. 1、初始化sp_pcontext的时候所有的参数都为0
  2. sp_pcontext::sp_pcontext(THD *thd)
  3.     : m_level(0),
  4.       m_max_var_index(0),
  5.       m_max_cursor_index(0)...{init(0, 0, 0, 0);}
  6. 2、每加一层sp_pcontext,当前的m_cursor_offset=上一层cursor个数
  7. sp_pcontext::sp_pcontext(THD *thd, sp_pcontext *prev,  
  8.                          sp_pcontext::enum_scope scope)
  9.     : m_level(prev->m_level + 1),
  10.       m_max_var_index(0),
  11.       m_max_cursor_index(0)... {init(prev->current_cursor_count());}
  12. void sp_pcontext::init(uint cursor_offset) {m_cursor_offset = cursor_offset;}
  13. uint current_cursor_count() const {
  14.     return m_cursor_offset + static_cast<uint>(m_cursors.size());
  15. }
  16. 3、退出当前sp_pcontext层,需要把当前的max_cursor_index()信息值赋值给上一层的m_max_cursor_index,即当前的cursor数量累加给上一层
  17. sp_pcontext *sp_pcontext::pop_context() {
  18.     uint submax = max_cursor_index();
  19.     if (submax > m_parent->m_max_cursor_index)
  20.       m_parent->m_max_cursor_index = submax;
  21. }
  22. uint max_cursor_index() const {
  23.     return m_max_cursor_index + static_cast<uint>(m_cursors.size());
  24.   }
  25. 4、每次增加一个cursor,m_max_cursor_index值递增,m_max_cursor_index是计数器。
  26. bool sp_pcontext::add_cursor(LEX_STRING name) {
  27.   if (m_cursors.size() == m_max_cursor_index) ++m_max_cursor_index;
  28.   return m_cursors.push_back(name);
  29. }
复制代码
2、根据第一步的分析,只在最里面那层的m_max_cursor_index累加出来计算错误,看看上面的累加过程,是用max_cursor_index()值来累加的,于是查看max_cursor_index()函数的实现:
  1. uint max_cursor_index() const {
  2.     return m_max_cursor_index + static_cast<uint>(m_cursors.size());
  3.   }
复制代码
这里是把当前层的m_max_cursor_index值加上m_cursors.size(),但是在函数add_cursor里面,m_cursors数组每增加一个cursor,m_max_cursor_index都要加1,也就是说在最里面那层sp_pcontext的计算重复了,计算了2遍m_cursors.size(),导致上面的level=2那层的m_max_cursor_index值变成2*4=8了。到这里问题点发现。
三、问题解决方案

通过以上代码解析后,可以考虑只对最里面那层sp_pcontext的max_cursor_index()取值进行修改,最里面那层的sp_pcontext没有m_children,因此可以用这个数组值进行判断。代码作如下修改:
  1. uint max_cursor_index() const {
  2.     if(m_children.size() == 0) -- 最里面那层sp_pcontext直接返回m_max_cursor_index的值。
  3.             return m_max_cursor_index; -- 可以改为static_cast<uint>(m_cursors.size()),二者值一样。
  4.     else -- 上层sp_pcontext返回下层所有sp_pcontext的m_max_cursor_index的值,再加上当前层的m_cursors.size()值。
  5.         return m_max_cursor_index + static_cast<uint>(m_cursors.size());
  6. }
复制代码
四、问题总结

在MySQL的sp里面使用cursor的话,因为m_max_cursor_index只用于统计,不用于实际赋值和计算过程,因此不影响使用。但是如果要用这个值用于二次开发,就要注意到这个问题。上面的修改方案只是其中一个解决方案,也可以根据自己的需要去改add_cursor的m_max_cursor_index的赋值过程。
这次发现的问题属于不参与计算的bug,但却影响开源代码的后续开发,在实际开发应用中类似的问题也要注意,一不小心就会踩坑。

Enjoy GreatSQL
来源:https://www.cnblogs.com/greatsql/p/18112051
免责声明:由于采集信息均来自互联网,如果侵犯了您的权益,请联系我们【E-Mail:cb@itdo.tech】 我们会及时删除侵权内容,谢谢合作!

举报 回复 使用道具