最可靠方式是SELECT输出变量值；它兼容性好、无需工具，但需在BEGIN...END内使用，避免生产环境长期保留，多变量可用SELECT v_a, v_b, v_c;配合临时表和DECLARE HANDLER可增强调试能力。
直接用 SELECT 输出变量值最可靠
MySQL 5.7 没有原生断点调试器，SELECT 是查看中间变量最直接、兼容性最好、无需额外工具的方式。它在执行到该语句时，会把变量值作为结果集返回，你能在客户端（如 MySQL CLI、Navicat、Workbench）立刻看到。
- 必须放在
BEGIN ... END块内，且不能在声明段之后、逻辑段之前（否则报错ERROR 1337: Variable 'xxx' is not declared） - 避免在生产环境长期保留——它会改变存储过程的返回结果集结构，可能破坏调用方解析逻辑
- 若变量为
NULL，SELECT v_var;会显示NULL；若想明确标注，可用SELECT 'v_var' AS name, v_var AS value; - 多个变量想一起看，写成
SELECT v_a, v_b, v_c;即可，不用逐行SELECT
用临时表记录执行轨迹，适合多步骤流程
当存储过程逻辑长、分支多，或需要回溯某次失败执行的完整路径时，CREATE TEMPORARY TABLE + INSERT 比一堆 SELECT 更清晰。
- 临时表只对当前会话可见，不用清理也不会污染全局；但若过程异常退出未显式
DROP，下次同名CREATE会报错ERROR 1050: Table 'debug_log' already exists - 推荐加时间戳字段：
create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP，便于排序定位执行顺序 - 不要在循环体里频繁
INSERT大量日志——MySQL 5.7 的临时表是内存表（MEMORY引擎），但大量插入仍可能触发磁盘溢出或锁等待 - 调试完记得删掉整段日志逻辑，或用条件开关包裹：
IF @debug_mode = 1 THEN INSERT INTO debug_log ... END IF;
DECLARE HANDLER 捕获错误并记录变量状态
很多问题只在特定输入下触发异常，而异常发生瞬间变量已丢失。用 DECLARE EXIT HANDLER FOR SQLEXCEPTION 可在出错前把关键变量快照存入日志表。
- 必须在
BEGIN后立即声明，否则作用域无效；且只能捕获运行时错误（如除零、主键冲突），不捕获语法错误或权限不足 -
GET DIAGNOSTICS只能取到错误码和消息，无法直接获取自定义变量值，所以需手动INSERT当前变量 - 示例中常漏掉
RESIGNAL或LEAVE，导致错误被静默吞掉，调用方收不到异常信号——调试阶段建议加RESIGNAL保证上层感知 - 注意：日志表本身不能是临时表（因 handler 执行时临时表可能已释放），得用普通表，如
error_log
别信“图形化调试器”的断点幻想
MySQL Workbench、Navicat、dbForge 等工具标榜的“单步调试”功能，在 MySQL 5.7 上本质是包装了 SELECT 插桩 + 客户端模拟执行流，并非真正 attach 到 mysqld 进程做内存级调试。
- 它们无法查看未显式输出的局部变量、无法观测 SQL 内部执行计划缓存状态、也无法在
PREPARE/EXECUTE动态语句内部设断点 - 某些版本在调试含游标或事务的存储过程时会卡死或跳过部分逻辑，尤其在 Windows 下连接超时设置不合理时
- 如果真要用，务必确认工具连接的是 MySQL 5.7 实例（不是 8.0+），且用户有
SELECT权限访问information_schema——否则调试界面加载失败却不报具体原因 - 最稳的组合仍是：CLI +
SELECT+ 日志表，三者互相验证，比依赖任一工具更可控
SELECT、临时表，还是两者嵌套。 
