当前位置：首页 > 文章列表 > 数据库 > MySQL > MySQL 事务里 GET DIAGNOSTICS 能解决什么：存储过程捕获错误与审计返回

MySQL 事务里 GET DIAGNOSTICS 能解决什么：存储过程捕获错误与审计返回

来源：17golang原创 2026-08-28 04:20:05 0浏览收藏

线上批量入库最怕的不是事务回滚，而是回滚以后只剩一句“操作失败”。调用方不知道是哪条约束出错，值班同事也无法把 SQLSTATE、MySQL 错误号和业务单号对应起来。MySQL 存储过程可以在异常处理器里用 GET DIAGNOSTICS 读取诊断区，再把关键信息写进审计表；如果还要让应用感知失败，则用 RESIGNAL 把原始错误继续抛出。

实用顺序是：先在 handler 里保存诊断信息，再回滚事务；需要保留数据库错误语义时，最后用 RESIGNAL 交给调用方，而不是用一条模糊提示覆盖它。

要点速览：

GET DIAGNOSTICS 分别读取 statement information 或 condition information，不能在同一条语句里混读。
要找主错误，先读取 NUMBER，再按返回的 condition 序号读取 MYSQL_ERRNO 和 MESSAGE_TEXT。
事务回滚解决数据一致性，审计表解决故障留痕，两者应在 handler 中明确分工。
RESIGNAL 适合在记录上下文后保留原始 SQLSTATE 和错误语义。

先划清 GET DIAGNOSTICS 能读什么

MySQL 的诊断区由两部分组成。statement information 记录条件数量和影响行数，常用字段是 NUMBER、ROW_COUNT；condition information 记录某个条件的 RETURNED_SQLSTATE、MYSQL_ERRNO、MESSAGE_TEXT 等信息。一个 SQL 语句没有产生条件时，condition area 为空。

这也是它和简单的 ROW_COUNT()、通用异常文本的区别：诊断区把“影响了多少行”和“为什么失败”分开保存。写存储过程时，先决定要记录哪一类信息，避免把两种读取方式写在同一条 GET DIAGNOSTICS 里。

从订单入库事务看完整处理链

下面用一张最小的审计表承接失败信息。示例只保留必要字段，生产环境可以再加入批次号、操作者或请求追踪号。

CREATE TABLE order_import_audit (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    batch_no VARCHAR(32) NOT NULL,
    sqlstate_value CHAR(5) NOT NULL,
    mysql_errno INT NOT NULL,
    message_text VARCHAR(255) NOT NULL,
    affected_rows INT NOT NULL,
    created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

事务流程可以拆成四段：写入订单、发生条件、handler 读取诊断区、回滚并记录。关键是不要在读取诊断区之前执行会覆盖当前诊断区的无关语句。

MySQL GET DIAGNOSTICS 先读取 NUMBER，再按 condition 序号取得 MYSQL_ERRNO 与 MESSAGE_TEXT 的错误链路

第一步：handler 里先保存 NUMBER

MySQL 手册提醒，CONDITION 1 不保证就是上一条语句的主要错误。因此比起直接读取第一条条件，更稳的顺序是先拿到 NUMBER，再读取最后一个 condition area。

DECLARE v_condition_count INT DEFAULT 0;
DECLARE v_sqlstate CHAR(5) DEFAULT '';
DECLARE v_errno INT DEFAULT 0;
DECLARE v_message VARCHAR(255) DEFAULT '';
DECLARE v_rows INT DEFAULT 0;

DECLARE EXIT HANDLER FOR SQLEXCEPTION
BEGIN
    GET DIAGNOSTICS v_condition_count = NUMBER;
    GET DIAGNOSTICS v_rows = ROW_COUNT;

    IF v_condition_count > 0 THEN
        GET DIAGNOSTICS CONDITION v_condition_count
            v_sqlstate = RETURNED_SQLSTATE,
            v_errno = MYSQL_ERRNO,
            v_message = MESSAGE_TEXT;
    END IF;

    ROLLBACK;
    INSERT INTO order_import_audit
        (batch_no, sqlstate_value, mysql_errno, message_text, affected_rows)
    VALUES
        (p_batch_no, v_sqlstate, v_errno, v_message, v_rows);
    RESIGNAL;
END;

这里的 NUMBER 只是条件区数量，不是错误号；ROW_COUNT 也不表示“事务最终提交了多少行”。如果失败发生在第一条写入语句，回滚后业务数据不会保留，但审计记录仍可以留下处理现场。

第二步：决定回滚、留痕和继续抛错的边界

EXIT HANDLER 接管异常后，最容易犯的错是只写一条固定文案，然后直接结束过程。这样调用方看不到原始 SQLSTATE，也无法根据 MYSQL_ERRNO 做重试或人工分流。上面的处理顺序把三个动作拆开：

读取：先把诊断变量复制出来，避免后续语句改变读取目标。
回滚：撤销订单写入，避免半批次数据留在业务表。
留痕：把批次号和错误字段写入 order_import_audit。
抛出：用 RESIGNAL 让上层连接继续拿到数据库错误。

MySQL 异常处理器通过 HANDLER 读取 GET DIAGNOSTICS，回滚并写审计后用 RESIGNAL 继续返回错误

第三步：用一个可失败样例验证结果

可以让导入过程接收批次号和订单号，然后故意插入一个已经存在的唯一键，检查应用返回值和审计表是否同时出现记录。

CALL import_one_order('B20260828-001', 10001);

SELECT batch_no, sqlstate_value, mysql_errno,
       message_text, affected_rows
FROM order_import_audit
WHERE batch_no = 'B20260828-001'
ORDER BY id DESC
LIMIT 1;

验证时看三件事：业务订单表没有半条新增记录；审计表有对应的 batch_no；客户端仍收到异常而不是“成功返回”。如果只看到审计记录、客户端没有错误，通常是 handler 没有使用 RESIGNAL，或者过程把异常转换成了普通返回值。

几个会让诊断结果失真的坑

不要把 CONDITION 1 当成固定主错误

多个条件同时出现时，条件区顺序不能简单理解成“第一条就是最终错误”。先取 NUMBER，再按实际数量读取目标 condition，更符合 MySQL 手册给出的处理方式。

不要在读取前调用会改写诊断区的语句

handler 中的第一批语句应专门做诊断变量赋值。把复杂的查询、打印或其他写操作放在前面，可能让你记录到后续语句的状态，而不是触发 handler 的原始条件。

不要把 ROW_COUNT 当成最终提交量

ROW_COUNT 对应的是诊断区里的受影响行数，适合说明某条 SQL 的结果；事务最终是否生效，仍要看 COMMIT 是否成功。发生异常并执行 ROLLBACK 后，业务表里的最终行数应单独复查。

适合落地的检查清单

检查点	应确认的内容	异常信号
读取顺序	先 NUMBER，再 CONDITION	固定读 CONDITION 1
数据一致性	handler 执行 ROLLBACK	业务表出现半批次
审计留痕	批次号、SQLSTATE、错误号、文本齐全	只有“失败”两个字
调用方语义	需要时执行 RESIGNAL	数据库异常被静默吞掉

小结

GET DIAGNOSTICS 的价值在于把存储过程里的失败变成可核对的数据：NUMBER 告诉你有多少条件，ROW_COUNT 描述语句影响行数，MYSQL_ERRNO、SQLSTATE 和 MESSAGE_TEXT 说明具体错误。围绕事务写入时，先保存诊断信息，再回滚、留痕，最后按需要 RESIGNAL，这条链路既保护数据，也保留了调用方需要的错误语义。