MySQL的多層SP中Cursor的m_max_cursor_index相關BUG分析

GreatSQL發表於2024-04-03
MySqlIndex

原始碼分析丨MySQL的多層SP中Cursor相關BUG

一、問題發現

在一次開發中在sp中使用多層cursor的時候想知道每層的m_max_cursor_index值分別是多少，以用來做後續開發。於是做了以下的試驗，但是發現第一個level=2那層的m_max_cursor_index的值有點問題。

注：本次使用的MySQL資料庫版本為最新的debug版本。

SQL語句示例：

greatsql> CREATE TABLE t1 (a INT, b VARCHAR(10));

以下注釋裡面是該層sp_pcontext的引數值。
DELIMITER $$
CREATE PROCEDURE processnames() -- level=0，m_max_cursor_index=1+8+1
BEGIN
    DECLARE nameCursor0 CURSOR FOR SELECT * FROM t1; -- level=1，m_cursor_offset=0，m_max_cursor_index=1+8+1
    begin
	   DECLARE nameCursor1 CURSOR FOR SELECT * FROM t1; -- level=2，m_cursor_offset=1，m_max_cursor_index=1+8 ☆問題點
       begin
			DECLARE nameCursor2 CURSOR FOR SELECT * FROM t1; -- level=3，m_cursor_offset=2，m_max_cursor_index=1
            DECLARE nameCursor3 CURSOR FOR SELECT * FROM t1; -- level=3，m_cursor_offset=2，m_max_cursor_index=2
            DECLARE nameCursor4 CURSOR FOR SELECT * FROM t1; -- level=3，m_cursor_offset=2，m_max_cursor_index=3
            DECLARE nameCursor5 CURSOR FOR SELECT * FROM t1; -- level=3，m_cursor_offset=2，m_max_cursor_index=4
        end;
   	end;
    begin
		DECLARE nameCursor6 CURSOR FOR SELECT * FROM t1; -- level=2，m_cursor_offset=1，m_max_cursor_index=1
   	end;
END $$
DELIMITER ;

首先檢視上面的sp的code，可以發現nameCursor6和nameCursor1屬於同一層，因此他們的offset值一樣。

greatsql>  show procedure code processnames;
+-----+---------------------------------------+
| Pos | Instruction                           |
+-----+---------------------------------------+
|   0 | cpush nameCursor0@0: SELECT * FROM t1 |
|   1 | cpush nameCursor1@1: SELECT * FROM t1 |
|   2 | cpush nameCursor2@2: SELECT * FROM t1 |
|   3 | cpush nameCursor3@3: SELECT * FROM t1 |
|   4 | cpush nameCursor4@4: SELECT * FROM t1 |
|   5 | cpush nameCursor5@5: SELECT * FROM t1 |
|   6 | cpop 4                                |
|   7 | cpop 1                                |
|   8 | cpush nameCursor6@1: SELECT * FROM t1 |
|   9 | cpop 1                                |
|  10 | cpop 1                                |
+-----+---------------------------------------+
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、初始化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_cast<uint>(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_cast<uint>(m_cursors.size());
  }

4、每次增加一個cursor，m_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_cast<uint>(m_cursors.size());
  }

這裡是把當前層的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，因此可以用這個陣列值進行判斷。程式碼作如下修改：

uint max_cursor_index() const {
    if(m_children.size() == 0) -- 最裡面那層sp_pcontext直接返回m_max_cursor_index的值。
    	return m_max_cursor_index; -- 可以改為static_cast<uint>(m_cursors.size())，二者值一樣。
    else -- 上層sp_pcontext返回下層所有sp_pcontext的m_max_cursor_index的值，再加上當前層的m_cursors.size()值。
        return m_max_cursor_index + static_cast<uint>(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-100-1-1.html

image-20230105161905827

技術交流群：

微信：掃碼新增GreatSQL社群助手微信好友，傳送驗證資訊加群。

image-20221030163217640

相關文章