MySQL GET DIAGNOSTICS 怎样读取存储程序的错误信息

我第一次把 MySQL 存储程序的异常信息接到业务返回值时，最容易混淆的是“语句执行了什么”和“为什么失败”其实不在同一组诊断信息里。GET DIAGNOSTICS 的正确用法是先判断语句级信息，再按条件编号读取 RETURNED_SQLSTATE、MYSQL_ERRNO 和 MESSAGE_TEXT。这样既能保留数据库原始错误，也能避免把空的表名、列名误当成完整错误。

本文只讨论 MySQL 8.4 的诊断区读取，不展开事务重试、业务补偿或客户端驱动封装。

先分清诊断区里到底存了什么

SQL 语句执行后会把诊断信息放入 diagnostics area。它包含两层：一层是语句信息，主要有条件数量 NUMBER 和影响行数 ROW_COUNT；另一层是条件信息，每个条件可以提供 SQLSTATE、MySQL 错误号和消息文本。

这两个层次不能在同一条 GET DIAGNOSTICS 语句里混用。例如读取 NUMBER 时不要同时写 CONDITION 1 ... MESSAGE_TEXT。先读数量，再决定是否继续读取具体条件，排查会更稳定。

先读取条件数量，再读取影响行数

在存储程序中，可以先把语句级信息放进局部变量。下面的片段适合放在刚执行完目标 SQL 的位置，避免后续语句覆盖你真正想看的诊断区。

-- 先保存语句级信息，判断是否有条件以及影响了多少行
GET CURRENT DIAGNOSTICS
  v_condition_count = NUMBER,
  v_affected_rows = ROW_COUNT;

-- 条件数量为零时，不要继续读取 CONDITION 1
IF v_condition_count = 0 THEN
  SET v_result = CONCAT('执行成功，影响行数=', v_affected_rows);
END IF;

CURRENT 可以省略，但我在排障代码中保留它，读者能直接看出这里读取的是当前诊断区。条件数量为零时继续读取 CONDITION 1 没有意义，还可能让错误处理逻辑变得难以判断。

在 handler 中提取 SQLSTATE、错误号和消息

真正需要保存错误信息时，通常把读取动作放在条件处理器里。下面的示例故意只返回稳定的三项：SQLSTATE 便于分类，MYSQL_ERRNO 便于和 MySQL 错误码对应，MESSAGE_TEXT 供日志或上层提示使用。

-- 这些变量负责承接数据库诊断区的原始信息
DECLARE v_sqlstate CHAR(5) DEFAULT '00000';
DECLARE v_errno INT DEFAULT 0;
DECLARE v_message TEXT DEFAULT '';
DECLARE v_result TEXT DEFAULT '';

-- 捕获插入异常，但把控制权交回后续的结果整理逻辑
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION
BEGIN
  -- 当前 handler 激活后，先读取当前条件的核心字段
  GET CURRENT DIAGNOSTICS CONDITION 1
    v_sqlstate = RETURNED_SQLSTATE,
    v_errno = MYSQL_ERRNO,
    v_message = MESSAGE_TEXT;
END;

-- 目标表的约束错误会进入上面的 handler
INSERT INTO orders(order_no) VALUES (v_order_no);

-- 用默认 SQLSTATE 判断插入是否顺利完成
IF v_sqlstate = '00000' THEN
  GET CURRENT DIAGNOSTICS v_affected_rows = ROW_COUNT;
  SET v_result = CONCAT('写入成功，影响行数=', v_affected_rows);
ELSE
  SET v_result = CONCAT('写入失败[', v_sqlstate, '/', v_errno, '] ', v_message);
END IF;

SELECT v_result AS result;

这里的关键不是把所有字段都读一遍，而是让 handler 只做“保存诊断信息”这件事。后面的判断、格式化和返回可以继续使用局部变量，减少后续 SQL 改写诊断区后造成的误读。

多条件和 CURRENT、STACKED 怎么处理

我在实际排查中遇到过一个看似偶发的误判：固定读取 CONDITION 1，拿到的并不一定是主错误。MySQL 文档明确提醒，多条件场景下第一条条件不保证就是主错误，更稳妥的办法是先读 NUMBER，再按返回的数量选择条件编号。

-- 多条件时先得到诊断区中的条件数量
GET CURRENT DIAGNOSTICS v_condition_count = NUMBER;

IF v_condition_count > 0 THEN
  -- 这里用最后一个条件编号读取更接近主错误的错误号与消息
  GET CURRENT DIAGNOSTICS CONDITION v_condition_count
    v_errno = MYSQL_ERRNO,
    v_message = MESSAGE_TEXT;
END IF;

STACKED 只在当前执行处于 condition handler 时可用，它指向进入 handler 前保存下来的第二个诊断区；CURRENT 指向当前诊断区。handler 内如果先执行了会产生新诊断信息的语句，再读取 CURRENT，看到的可能已经不是原始异常，所以需要先保存，再做映射或补偿。

我的值班处理顺序通常是：先保存 SQLSTATE、错误号和消息，再判断是否需要回滚或转换结果；如果要分析 handler 触发前的原始条件，则读取 STACKED，并且不要在普通 SQL 提示符下使用它。离开 handler 后，优先使用已经保存的局部变量，而不是依赖诊断区仍然保持原样。

常见问题

为什么读取 CONDITION 1 得不到想要的错误？

因为语句可能产生多个条件，MySQL 不保证第一条就是主错误。先读取 NUMBER，再按条件编号取错误字段。

GET DIAGNOSTICS 能不能读取影响行数？

可以，影响行数属于语句信息，使用 ROW_COUNT，不要写成 CONDITION n 下的字段。

什么时候不能使用 GET STACKED DIAGNOSTICS？

不在 condition handler 上下文时不能使用；此时应读取当前诊断区，或在 handler 内先把需要的值保存下来。

把 GET DIAGNOSTICS 当成“先读语句层、再读条件层”的两段式接口，存储程序里的错误处理就会清晰很多：成功路径看 ROW_COUNT，异常路径保留 SQLSTATE、错误号和消息，多条件场景再根据 NUMBER 选择条件。