MySQL 处理器中 STACKED 与 CURRENT 诊断区有什么区别

我在排查存储过程异常时最容易踩的坑，是把 handler 里的 GET CURRENT DIAGNOSTICS 当成“原始错误快照”。实际上，CURRENT 指向处理器当前的诊断区，handler 中的 SET、INSERT 等语句都可能让它发生变化；STACKED 指向进入 handler 前保留下来的第二诊断区，适合读取真正触发处理器的条件。

官方文档地址：https://dev.mysql.com/doc/refman/8.4/en/get-diagnostics.html

先把两个诊断区放回同一张“栈”里理解

MySQL 的诊断区包含语句级信息和条件级信息。NUMBER、ROW_COUNT 属于前者，RETURNED_SQLSTATE、MYSQL_ERRNO、MESSAGE_TEXT 属于后者。普通 SQL 语句执行后，当前诊断区会被清理并重新填充。

当条件处理器被激活时，原来的当前诊断区被压到栈的下一层，成为 STACKED；MySQL 再创建一个新的 CURRENT 给 handler 使用。新 CURRENT 开始时通常是原诊断区的副本，所以 handler 的第一条读取语句可能看到相同内容。区别从 handler 执行第一条会改变诊断区的语句后开始显现。

处理原始异常时，先读 STACKED 再做动作

如果目标是记录“为什么进入 handler”，最稳妥的顺序是把变量声明放在外层，并在 handler 的开头读取 STACKED。这样即使后面要写审计表、设置状态或执行补偿 SQL，也不会丢掉原始错误。

-- 准备一个不允许 NULL 的示例表
CREATE TABLE demo_orders (
  note TEXT NOT NULL
);

DELIMITER //
CREATE PROCEDURE save_order_note()
BEGIN
  -- 变量放在处理器外，避免进入处理器后的声明语句干扰 CURRENT
  DECLARE v_source_errno INT;
  DECLARE v_source_state CHAR(5);
  DECLARE v_source_message TEXT;
  DECLARE v_current_number INT;

  DECLARE EXIT HANDLER FOR SQLEXCEPTION
  BEGIN
    -- 先固定触发处理器的原始条件，不依赖 CURRENT 是否已被改写
    GET STACKED DIAGNOSTICS CONDITION 1
      v_source_errno = MYSQL_ERRNO,
      v_source_state = RETURNED_SQLSTATE,
      v_source_message = MESSAGE_TEXT;

    -- 这里可以把原始错误写入审计表或日志表
    SET @last_errno = v_source_errno;
    SET @last_state = v_source_state;
    SET @last_message = v_source_message;

    -- SET 之后再读 CURRENT，得到的是处理器当前动作的诊断状态
    GET CURRENT DIAGNOSTICS v_current_number = NUMBER;
  END;

  -- 这个 NULL 会触发 1048 条件，示例重点是诊断区读取顺序
  INSERT INTO demo_orders(note) VALUES (NULL);
END//
DELIMITER ;

这个例子没有把某个预期输出冒充成本机运行证据。它要表达的是读取时机：v_source_* 记录的是触发 handler 的条件，而 v_current_number 只用于观察 handler 当前诊断区。若处理器还要执行补偿插入，建议先保存 STACKED，再判断补偿语句之后 CURRENT 的 NUMBER，不要用补偿成功后的 CURRENT 反推原始异常。

什么时候用 CURRENT，什么时候必须用 STACKED

可以按“我要查哪一次动作”来选择。处理器外刚执行完一条 SQL，读取 CURRENT 就够了；MySQL 允许在这种场景使用 GET [CURRENT] DIAGNOSTICS。而在 handler 内需要追溯触发条件时，应优先 STACKED。STACKED 只能在条件处理器活动期间使用，在普通会话中直接执行会报 handler 未激活的错误。

还有一个细节值得记住：handler 进入时 CURRENT 与 STACKED 可能相同，但这不是“两个别名”。处理器中的非诊断语句通常会清理或重置 CURRENT；STACKED 在 handler 内保持不变，只有 RESIGNAL 这类操作会参与原条件的传递。因此日志代码应先写 STACKED，再执行任何可能产生新诊断信息的语句。

常见问题

处理器外可以直接使用 GET STACKED DIAGNOSTICS 吗？

不可以。STACKED 诊断区依赖正在执行的条件处理器；处理器外应使用默认的 CURRENT 诊断区。

为什么 handler 开头读 CURRENT 有时也能拿到原错误？

因为 handler 激活时新的 CURRENT 通常从原诊断区复制而来。但只要前面执行了会改变诊断区的语句，这个偶然成立的结果就不可靠，追溯原异常应读取 STACKED。

读取 CONDITION 1 前为什么要先看 NUMBER？

NUMBER 表示当前诊断区的条件数量。先判断数量，再读取对应编号，可以避免在没有条件时读取不存在的条件项。

实际开发中可以把规则压缩成一句话：要看 handler 现在发生了什么，用 CURRENT；要保住 handler 为什么被触发，用 STACKED。先保存原条件，再做补偿、审计和 RESIGNAL，诊断日志才不会被后续动作覆盖。