MySQL 5.7存储过程调试核心是状态可捕获、可回溯、可隔离：优先用SELECT输出变量（需客户端支持多结果集），真要落库须用InnoDB日志表+SET autocommit=1+JSON_OBJECT安全拼接，卡顿时须借performance_schema查内部SQL耗时与扫描行数定位根因。
MySQL 5.7 没有原生断点调试器，调试长存储过程的核心不是“暂停执行”，而是“让状态可捕获、可回溯、可隔离”。直接用 SELECT 输出变量最轻量，但必须配合客户端多结果集支持；真要持久化日志，必须写入 InnoDB 表且绕过主事务影响；卡住时别只看 SHOW PROCESSLIST，得立刻切到 performance_schema 查线程内部 SQL。
为什么 SELECT 'debug:', @var 在很多客户端里会报 Commands out of sync
这不是你的 SQL 写错了，是客户端驱动默认禁用了多结果集。MySQL 存储过程里执行 SELECT 会产生一个独立结果集，而多数应用连接（比如 JDBC 默认配置、某些命令行工具）只准备接收主查询结果，遇到第二个结果集就抛 Commands out of sync; you can't run this command now。
- MySQL Workbench 和 DBeaver 默认开启多结果集，适合开发阶段快速打点
- PHP 的
mysqli需手动调用mysqli_next_result()才能取到后续SELECT结果 - 生产环境绝对不要依赖
SELECT做日志——它不落盘、不可查、无法关联执行上下文 - 临时救急可以加
SELECT SLEEP(0.1)缓冲，但这只是掩盖问题，不是解决
INSERT INTO debug_log 必须满足的三个硬性条件
想把日志写进表里又不拖慢主流程、不被事务回滚带走、还能防注入，INSERT 不能随便写。以下三点缺一不可：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 日志表引擎必须是
InnoDB，且建表时显式指定ENGINE=InnoDB（避免因 sql_mode 或版本差异落到 MyISAM） - 插入语句必须用
INSERT INTO sp_debug_log SET proc_name = ..., step = ..., data = JSON_OBJECT(...)，禁止字符串拼接VALUES ('xxx', 'yyy', CONCAT(...)) - 必须在存储过程开头加
SET autocommit = 1;，否则日志写入会被包裹在主事务里，ROLLBACK时一并消失 - 如果日志量大（比如循环内每轮都记），务必前置判断：
IF @debug_mode = 1 THEN INSERT ... END IF;
CALL 卡住时如何 2 分钟内定位到具体哪条 SQL 在拖慢
SHOW FULL PROCESSLIST 只告诉你“有个 CALL 在跑”，但真正吃资源的是它里面嵌套的 SQL。必须用 performance_schema 穿透进去：
- 先执行
SELECT ID, INFO FROM INFORMATION_SCHEMA.PROCESSLIST WHERE COMMAND = 'Execute' AND INFO LIKE 'CALL%';拿到线程ID - 再查
SELECT THREAD_ID, EVENT_NAME, SQL_TEXT, TIMER_WAIT/1000000000000 AS sec FROM performance_schema.events_statements_current WHERE THREAD_ID = 12345 AND EVENT_NAME = 'statement/sql/call';确认确实是 CALL 入口 - 最后查
SELECT SQL_TEXT, ROWS_EXAMINED, ROWS_SENT, TIMER_WAIT/1000000000000 AS sec FROM performance_schema.events_statements_history_long WHERE THREAD_ID = 12345 ORDER BY EVENT_ID DESC LIMIT 10; - 重点盯
ROWS_EXAMINED >> ROWS_SENT的语句——这大概率是没走索引的全表扫描，或隐式类型转换导致索引失效
OUT 参数取不到值？90% 是变量遮蔽或未初始化
CALL proc(@a, @b); SELECT @a; 返回 NULL，几乎可以确定不是存储过程逻辑问题，而是作用域陷阱：
- 调用前没初始化：
SET @a = NULL;必须显式写，不能依赖“默认为 NULL”——某些 MySQL 版本或连接模式下未声明的用户变量行为不一致 - 存储过程中写了
DECLARE a INT;—— 这会遮蔽传入的@a，后续所有对a的赋值都只影响局部变量，@a保持原值 - 正确做法：存储过程内部直接操作
@a，不声明同名局部变量；如需中转，明确写SET @a = local_var; - 字符集也会影响：若客户端连接用
utf8mb3，而OUT参数是TEXT类型，可能静默截断，改用utf8mb4连接再试
最易被忽略的一点：日志表字段 data JSON 在 MySQL 5.7 中要求输入严格 JSON 格式，JSON_OBJECT('key', @val) 是安全的，但 CONCAT('{ "key": "', @val, '" }') 一旦 @val 含双引号或反斜杠就会解析失败，整条 INSERT 被静默跳过——查不到日志，不代表没执行。
