MySQL存储过程在执行异常时，默认的返回信息往往非常有限。调用端可能只收到一个SQLSTATE或错误编号，无法直接看出是存储过程中的哪一条SQL出错，更不知道执行到了哪一步。如果存储过程内部还声明了CONTINUE HANDLER，某些错误会被当作正常流程继续执行，问题只会以数据不一致或结果缺失的方式暴露出来，排查难度更高。要高效定位异常，首先要转变排查思路：不要等着错误自己冒出来，而是让错误在发生时主动留下足够的现场信息。
用DECLARE HANDLER主动记录错误现场
存储过程提供了一套条件处理机制，可以在异常发生时执行指定的代码块。通常建议在敏感存储过程的骨架中加入一个EXIT HANDLER或CONTINUE HANDLER，用来捕获SQLEXCEPTION、SQLWARNING以及NOT FOUND三种基础条件。EXIT HANDLER会在处理完异常后终止当前存储过程的执行，而CONTINUE HANDLER处理完后会继续从出错的下一条语句运行。对于排查场景，更推荐使用EXIT HANDLER配合错误日志表，因为这样可以在保留现场的同时，避免后续语句基于错误状态继续运行产生二次问题。
只捕获异常还不够，还要拿到异常的详细信息。MySQL从5.6版本开始支持GET DIAGNOSTICS语句，可以读取当前诊断区中的错误码、错误消息以及SQLSTATE。通过把这三项信息写入一个专门的过程日志表，就能在问题发生后回溯每一次失败的原因。下面是一个简单的日志表结构和带错误捕获的存储过程模板：
CREATE TABLE proc_error_log (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
proc_name VARCHAR(100),
error_time DATETIME,
error_code INT,
error_state CHAR(5),
error_message TEXT
);
DELIMITER $$
CREATE PROCEDURE demo_proc()
BEGIN
DECLARE v_code INT DEFAULT 0;
DECLARE v_state CHAR(5) DEFAULT '00000';
DECLARE v_msg TEXT;
DECLARE EXIT HANDLER FOR SQLEXCEPTION
BEGIN
GET DIAGNOSTICS CONDITION 1
v_code = MYSQL_ERRNO,
v_state = RETURNED_SQLSTATE,
v_msg = MESSAGE_TEXT;
INSERT INTO proc_error_log(proc_name, error_time, error_code, error_state, error_message)
VALUES ('demo_proc', NOW(), v_code, v_state, v_msg);
RESIGNAL;
END;
-- 实际业务SQL
SELECT * FROM non_exist_table;
END$$
DELIMITER ;
在这个示例中，当业务SQL出现错误时，EXIT HANDLER会立即触发，把错误编号、SQLSTATE和错误消息写入proc_error_log表，然后通过RESIGNAL把原始错误继续抛给调用端。这样既不会破坏存储过程对外抛错的行为，又能在日志表中留一份可查询的记录。如果希望观察错误后继续执行，也可以把EXIT HANDLER改成CONTINUE HANDLER，但需要注意，RESIGNAL在CONTINUE HANDLER中的使用可能需要额外判断，否则容易造成循环处理。
如果存储过程比较长，仅仅知道错误消息还不够，还需要知道错误发生前执行到了哪一步。这时可以在每个关键业务节点前插入一条步骤日志。步骤日志和错误日志可以合并成一张表，也可以单独维护一张追踪表。例如在进入某个事务前记录before_order_insert，在订单表插入后记录after_order_insert，这样当错误日志中的时间点与步骤日志匹配后，就能把失败范围缩小到两条相邻步骤日志之间。
不改存储过程时的外部排查手段
很多时候生产环境的存储过程不允许直接修改定义，或者异常是偶发的，不方便重新部署带日志的版本。此时需要依赖MySQL提供的外部观测能力。第一步通常从查看存储过程的元数据开始。使用SHOW PROCEDURE STATUS LIKE 'demo_proc'可以拿到存储过程的名字、创建时间、修改时间、安全类型和注释等信息。使用SHOW CREATE PROCEDURE demo_proc则可以查看完整的定义语句，确认当前数据库中的版本是否与代码仓库一致。很多线上事故的根源并不是SQL逻辑本身，而是某次发布没有真正覆盖到目标库。
当元数据没有异常时，可以进一步启用通用查询日志。通用日志会记录MySQL收到的每一条SQL，包括存储过程内部执行的语句。不过在生产环境中直接打开general_log对性能影响较大，通常建议在低峰期短时间开启，并把日志输出到表而不是文件，方便按时间过滤。打开方法如下：
SET GLOBAL log_output = 'TABLE'; SET GLOBAL general_log = 'ON'; SELECT event_time, command_type, argument FROM mysql.general_log WHERE argument LIKE '%demo_proc%' ORDER BY event_time DESC LIMIT 200; SET GLOBAL general_log = 'OFF';
需要注意的是，mysql.general_log表在MySQL 8.0中可能需要在开启日志后才能查询到有意义的数据，且高并发场景下这张表会迅速增长。查询完毕后应尽快关闭general_log，必要时清理日志表内容。如果异常表现为某条SQL执行很慢而不是直接报错，则慢查询日志更能发挥作用。慢日志记录执行时间超过阈值的语句，结合时间点可以判断存储过程中的哪条SQL出现了性能抖动。
从MySQL 5.6开始，performance_schema也提供了语句执行历史。events_statements_history_long表保存了最近执行过的若干条语句，其中包含来自存储过程内部的SQL。通过查询该表，可以不用开启general_log就能看到存储过程内部最近执行了哪些语句、耗时多少、返回行数是多少。下面这条查询可以按执行时间倒序查看与存储过程相关的语句：
SELECT s.THREAD_ID, s.EVENT_ID, s.EVENT_NAME, s.SQL_TEXT, s.TIMER_WAIT / 1000000000000 AS exec_time_ms, s.ERRORS, s.WARNINGS, s.ROWS_AFFECTED, s.CREATED_TMP_DISK_TABLES, s.NO_INDEX_USED FROM performance_schema.events_statements_history_long s WHERE s.SQL_TEXT LIKE '%demo_proc%' OR s.SQL_TEXT LIKE '%non_exist_table%' ORDER BY s.TIMER_START DESC LIMIT 100;
这段查询中的TIMER_WAIT需要除以1000000000000才能换算成毫秒，具体换算关系取决于服务器配置，但这一写法在多数环境下可行。如果performance_schema没有开启对应的消费者，查询结果可能为空，此时需要检查setup_consumers表中相关配置是否处于启用状态。
从锁等待和事务状态查找间歇性异常
有些存储过程异常与SQL语法无关，表现为偶发的锁等待超时、死锁回滚或者事务长时间未提交。这类问题使用错误日志表和慢日志往往只能看到一声超时或死锁，很难定位真正阻塞来源。对于InnoDB存储引擎，第一步应该查看SHOW ENGINE INNODB STATUS的输出。该命令会返回一段较长的文本，其中LATEST DETECTED DEADLOCK部分描述了最近一次死锁的参与事务和锁信息，TRANSACTIONS部分可以看到当前活跃事务的状态。
如果怀疑是锁等待导致的超时，需要实时查看当前锁的持有和等待情况。MySQL 8.0推荐使用performance_schema中的data_locks和data_lock_waits表，这两个表可以展示每个锁的持有线程、等待线程、锁类型和锁定对象。下面是一个查询锁等待关系的常用SQL：
SELECT r.trx_id AS waiting_trx_id, r.trx_mysql_thread_id AS waiting_thread, r.trx_query AS waiting_query, b.trx_id AS blocking_trx_id, b.trx_mysql_thread_id AS blocking_thread, b.trx_query AS blocking_query FROM information_schema.innodb_lock_waits w JOIN information_schema.innodb_trx b ON b.trx_id = w.blocking_trx_id JOIN information_schema.innodb_trx r ON r.trx_id = w.requesting_trx_id;
在MySQL 8.0中，information_schema.innodb_lock_waits仍然保留，但官方推荐逐步迁移到performance_schema.data_lock_waits。实际排查时，如果发现存储过程开启事务后长时间不提交，应该检查代码中是否缺少COMMIT或ROLLBACK，或者是否存在游标未关闭、异常处理后事务状态不完整等情况。对于一个存储过程来说，最稳妥的做法是把事务边界控制在最小范围内，并在EXIT HANDLER中根据条件执行ROLLBACK，避免把未提交事务带到连接池外层。
还需要重视死锁日志中的SQL语句。死锁发生时，InnoDB会记录两个事务各自已经持有的锁和正在等待的锁，以及对应的SQL语句。把这些SQL与存储过程源码进行比对，可以判断是哪个存储过程中的哪条语句参与了死锁。由于死锁回滚通常只会影响一个事务，调用方可能看到死锁错误并重试，但存储过程内部如果没有正确处理重试，就会把错误往外层抛。可以根据业务情况在存储过程外层或应用层设计有限次数的重试机制，但要注意幂等性。
构建可追踪的存储过程调试骨架
对于复杂存储过程，最好在开发阶段就加入轻量级追踪代码。不要把追踪逻辑写得到处都是，可以通过一个统一的trace表和一个简单的插入封装来实现。由于MySQL存储过程不容易像高级语言一样方便地格式化输出局部变量，可以借助CONCAT函数把变量值拼接到追踪消息中。下面是一个可复用度较高的追踪表示例：
CREATE TABLE proc_trace_log (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
proc_name VARCHAR(100),
step_name VARCHAR(100),
step_time DATETIME,
detail TEXT
);
DELIMITER $$
CREATE PROCEDURE debug_proc()
BEGIN
DECLARE v_step VARCHAR(100) DEFAULT 'start';
DECLARE v_order_count INT DEFAULT 0;
INSERT INTO proc_trace_log(proc_name, step_name, step_time, detail)
VALUES ('debug_proc', v_step, NOW(), CONCAT('order_count=', v_order_count));
SET v_step = 'after_select_count';
SELECT COUNT(*) INTO v_order_count
FROM orders
WHERE status = 'PAID';
INSERT INTO proc_trace_log(proc_name, step_name, step_time, detail)
VALUES ('debug_proc', v_step, NOW(), CONCAT('order_count=', v_order_count));
SET v_step = 'before_update';
-- 实际更新逻辑
END$$
DELIMITER ;
这种骨架的好处是排查问题时不需要猜测。只要查询proc_trace_log表，按id或时间排序，就能看到存储过程走到了哪一步，每一步的关键变量值是什么。对于生产环境，可以在部署完成后统一删除或关闭追踪插入，也可以使用一个全局参数控制是否记录追踪。MySQL存储过程没有提供条件编译，但可以通过IF判断一个配置变量来决定是否写入追踪表，这样在生产稳定运行阶段可以降低追踪开销。
存储过程异常排查并不是某一条命令就能立刻解决的问题，更多时候需要把错误捕获、步骤追踪、日志分析和锁分析组合起来。先回答“错误发生在哪一步”，再回答“这一步具体是哪条SQL或哪个资源竞争导致的”，最后通过修复事务边界、索引设计或业务逻辑来消除根因。按照这个顺序处理，大部分MySQL存储过程执行异常都能在较短时间内定位并解决。