MySQL存储过程报错行号指向CREATE语句而非实际错误位置，应通过SELECT打点、分段调用、GET DIAGNOSTICS获取错误详情、通用日志追踪执行流等方式精准定位问题。
直接看错误信息里的行号不靠谱
MySQL 报错时显示的“Line X”通常指 CREATE PROCEDURE 语句本身的第 X 行，不是存储过程内部执行出错的实际位置。比如你写了个 50 行的存储过程，报错说 ERROR 1054 (42S22): Unknown column 'xxx' in 'field list' at line 32，这个 32 是 CREATE 语句里第 32 行（可能只是个 END;），根本不是 SELECT 或 INSERT 出问题的地方。
用 SELECT 打点 + 分段调用是最稳的定位法
没有断点调试，就靠人工“打桩”。在关键逻辑前后插入 SELECT 输出标记和变量值，调用时逐段注释掉后续代码，缩小范围。
- 在每个
SET、INSERT、SELECT ... INTO前后加SELECT 'before insert', v_id, v_name; - 特别注意
SELECT ... INTO：如果查不到数据，会直接触发NOT FOUND异常，但默认不报错——除非你加了DECLARE CONTINUE HANDLER FOR NOT FOUND且没处理好 - 游标循环里务必设标志位，例如
DECLARE done INT DEFAULT FALSE;+DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;，否则第一次 fetch 就可能静默失败 - 避免把多条语句压缩在一行，比如
SET a=1; SELECT a; INSERT ...;—— 这会让SELECT输出和后续错误混在一起，难以区分
GET DIAGNOSTICS 能拿到错误细节，但得配合 HANDLER
只写 DECLARE EXIT HANDLER FOR SQLEXCEPTION 不够，它捕获错误但不告诉你哪条语句崩了。必须立刻用 GET DIAGNOSTICS 提取上下文：
DECLARE EXIT HANDLER FOR SQLEXCEPTION
BEGIN
GET DIAGNOSTICS CONDITION 1
@sqlstate = RETURNED_SQLSTATE,
@errno = MYSQL_ERRNO,
@text = MESSAGE_TEXT,
@table = TABLE_NAME,
@column = COLUMN_NAME;
SELECT 'ERROR IN PROC', @sqlstate, @errno, @text, @table, @column;
END;
注意：@table 和 @column 在某些错误类型下为空（比如语法错误或权限问题），但 @errno 和 @text 总是有效，能帮你锁定是字段不存在（1054）、表不存在（1146）还是唯一冲突（1062）。
通用查询日志（general_log）适合查执行流，别在生产开
当 SELECT 打点还不够，怀疑是参数传入或隐式类型转换导致的问题，可以临时打开通用日志看 MySQL 实际执行了什么：
- 执行
SET GLOBAL general_log = ON;和SET GLOBAL general_log_file = '/tmp/mysql-general.log'; - 调用存储过程，然后
tail -n 100 /tmp/mysql-general.log查最后几条记录 - 你会看到类似
CALL debug_proc();→SELECT name FROM users WHERE id = 100;→INSERT INTO log_table VALUES (...);的完整链条 - ⚠️ 别在生产环境开：日志体积爆炸、性能下降明显，且含敏感参数值
真正难定位的，往往是嵌套调用里某一层悄悄吞了异常，或者 handler 没写 RESIGNAL 导致错误被吃掉——这种时候，光看最终报错毫无意义，必须从入口开始逐层加 SELECT 和 GET DIAGNOSTICS。
