MySQL存储过程日志应优先用SELECT CONCAT调试，避免INSERT拖慢性能；真需落库则用BLACKHOLE/CVS引擎或应用层异步写入；卡顿多因锁等待或循环未退出；OUT参数失效常因变量作用域错误；调试可用LEAVE标签跳过逻辑段。
MySQL存储过程里怎么加日志，又不拖慢线上性能
直接写 INSERT INTO log_table 是最常见做法，但高频调用时会明显拖慢主流程——尤其当存储过程本身在事务里、且日志表没建好索引或用了 InnoDB 默认隔离级别时，日志写入可能成为锁瓶颈。
真正可行的日志方案得兼顾「可查」和「低侵入」：
- 优先用
SELECT CONCAT(...)拼接调试信息，配合客户端（如 MySQL Workbench）的“执行并查看结果集”功能，避免落盘； - 真要落库，日志表必须用
ENGINE=BLACKHOLE（开发/测试环境），或ENGINE=CSV（临时导出用），绕过事务和锁； - 生产环境如必须持久化，日志表单独建，
INSERT改为INSERT DELAYED（MySQL 5.6+ 已废弃，5.7+ 请改用应用层异步写入）； - 别在循环体里反复
INSERT，合并成单条INSERT ... VALUES (...), (...), (...)批量写入。
CALL 过程卡住没反应？先确认是不是被锁或死循环
大型存储过程挂起，90% 不是代码 bug，而是隐式锁等待或条件判断失效导致无限等待。比如 WHILE NOT done DO ... END WHILE 里 done 变量没被正确置为 TRUE，或者游标 FETCH 后没检查 NOT FOUND 就继续循环。
快速定位方法：
- 开另一个会话，查
SHOW PROCESSLIST，看状态是不是Sleep、Locked或长时间Updating； - 对目标会话执行
SELECT * FROM performance_schema.events_statements_current WHERE THREAD_ID = ?（需提前开启相关 consumers）； - 在关键节点插入
SELECT 'at step A', @var1, @var2;，靠结果集输出位置判断卡点； - 禁用自动提交：
SET autocommit = 0;再CALL，方便后续用ROLLBACK中断并观察中间状态。
为什么 OUT 参数在 CALL 后取不到值？变量作用域搞错了
CALL proc(@a, @b) 之后查 SELECT @a 返回 NULL，大概率是：调用前没初始化，或存储过程中把 @a 当局部变量重新声明了（比如写了 DECLARE a INT），导致同名用户变量被遮蔽。
安全写法只有两种：
- 调用前显式初始化：
SET @a = NULL; SET @b = ''; CALL proc(@a, @b);； - 存储过程内部不声明同名变量，所有 OUT/INOUT 参数直接用传入的用户变量名操作；
- 如果必须用局部变量做中转，赋值时明确写
SET @a = local_var;，别依赖隐式返回； - 注意字符集：若 OUT 参数是
TEXT类型，而客户端连接用的是utf8mb3，可能截断或乱码，查SELECT CHARSET(@a)确认。
调试超长存储过程，怎么跳过已验证的段落
没法像高级语言那样设断点，但可以用 LEAVE + 标签快速“注释掉”大段逻辑。比如想只跑前半部分，就在中间加个标签和跳转：
my_exit: BEGIN
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION
LEAVE my_exit;
-- 正常逻辑...
LEAVE my_exit; -- 这行一加，后面全跳过
-- 后半部分大量计算/更新...
END比删代码安全，比注释易恢复，也比反复 DROP PROCEDURE + CREATE 快得多。唯一要注意：标签名不能和已有语句块重名，否则报错 Label 'xxx' is not found。
复杂点在于嵌套块里的标签可见性——外层标签不能被内层 LEAVE 直接引用，必须显式写成 LEAVE outer_label;，否则只会跳出当前 BEGIN...END 块。
