MySQL 存储过程中无法直接开启执行日志
MySQL 本身不提供类似 Oracle 的 DBMS_OUTPUT 或 SQL Server 的 PRINT 那种内置过程级调试输出机制，也没有原生的「存储过程每行执行都记日志」开关。所谓「过程级日志记录」，实际是靠间接手段拼出来的——不是开个配置就能自动打日志，而是得你自己埋点、选通道、控粒度。
用 SELECT 语句临时输出调试信息（最轻量但有限制）
在开发/测试阶段，最常用的是在关键位置插入 SELECT 输出变量或状态，配合客户端工具（如 MySQL Shell、DBeaver、Navicat）查看结果集。但它只对交互式会话有效，且不能写入文件或系统日志。
-
SELECT不能出现在函数定义里，只能用于存储过程（PROCEDURE），否则报错ERROR 1418 (HY000) - 多个
SELECT会产生多个结果集，客户端需支持逐个读取（命令行客户端默认只显示最后一个） - 生产环境禁用：会暴露敏感值、拖慢执行、干扰调用方逻辑（比如应用 expecting single result）
示例：
DELIMITER $$<br>CREATE PROCEDURE debug_demo()<br>BEGIN<br> DECLARE v_count INT DEFAULT 0;<br> SELECT CONCAT('start, count=', v_count) AS debug_info;<br> SET v_count = v_count + 1;<br> SELECT CONCAT('after inc, count=', v_count) AS debug_info;<br>END$$<br>DELIMITER ;
用表记录日志（可控、可查、适合中低频调试）
建一张专用日志表，用 INSERT 记录时间、过程名、参数、关键变量、错误码等。这是线上环境最稳妥的过程级审计方式，但要注意性能和清理策略。
- 日志表引擎建议用
InnoDB（事务安全），避免MyISAM在高并发下锁表 - 字段别太宽：比如
proc_name VARCHAR(64)足够，不用TEXT；时间用NOW(3)带毫秒精度 - 别在循环体里频繁
INSERT，尤其大结果集处理时——考虑批量缓存后一次写入，或改用应用层异步落库 - 记得加索引：至少在
created_at和proc_name上建复合索引，否则查三天前某过程的日志会全表扫
建表示例：
CREATE TABLE proc_debug_log (<br> id BIGINT PRIMARY KEY AUTO_INCREMENT,<br> proc_name VARCHAR(64) NOT NULL,<br> params TEXT,<br> context TEXT,<br> created_at DATETIME(3) DEFAULT NOW(3)<br>) ENGINE=InnoDB;
启用 general_log 或 slow_query_log 不解决过程内部问题
这两个全局日志只记录到达 server 层的语句，即「调用存储过程的那条 CALL xxx()」，而不会展开记录过程体内的 SET、IF、INSERT 等——它们被当成一个原子操作执行，server 日志里就一行。
- 开启
general_log会导致 I/O 暴涨，线上严禁长期开启；即使开了，你也看不到过程里DECLARE v_xxx的值变化 -
slow_query_log只统计总耗时，无法定位是哪条UPDATE卡住还是循环次数超预期 - 想看内部执行路径，必须回到前面两种方式：手动埋点（
SELECT或INSERT）
真正难的不是“怎么记”，而是“记什么”和“什么时候停”。过程嵌套深、分支多、参数动态拼接时，日志容易爆炸或漏关键路径。上线前得想清楚：这条日志是用来查故障？做行为审计？还是仅临时排障？目标不同，埋点位置和字段设计就完全不同。
