不能只靠select打印变量定位逻辑漏洞，因其会中断执行流、干扰事务并无法暴露分支跳转错误；需用覆盖边界值、预置数据状态、清空调试表的单元测试，并通过declare handler和调试表精准捕获隐式逻辑错误。
为什么不能只靠 SELECT 打印变量来定位逻辑漏洞
因为 SELECT 输出会中断存储过程的执行流——尤其在事务中，它可能提前提交隐式结果集，干扰后续语句的执行顺序或触发客户端异常；更关键的是，它完全无法暴露分支跳转错误（比如 IF ... ELSE 漏写 ELSE，导致某路径下变量未赋值却继续使用）。这类问题不会报错，但数据结果错得离谱，且日志里毫无痕迹。
真正要验证逻辑，必须让每条分支都走通、每种输入组合都被覆盖，而不是“看到变量值就放心”。
构造有效单元测试用例的 3 个硬性条件
存储过程不是函数，没有返回值，所以测试必须围绕「副作用」设计：表变更、临时表内容、输出参数、错误状态。满足以下三点才算可用：
- 输入参数必须覆盖边界值：
NULL、空字符串、超长字符串、负数、极大整数、非法日期（如'2025-02-30'） - 涉及的数据状态必须预置：比如测试扣款过程，需提前插入余额为 0、余额不足、余额刚好够三种账户记录
- 每次运行前清空调试表和目标表：避免上一轮残留数据污染本轮结果，尤其当过程含
INSERT ... ON DUPLICATE KEY UPDATE时
用 DECLARE HANDLER 捕获并暴露隐藏逻辑错误
很多逻辑漏洞本质是“没出错，但不该发生的事发生了”，比如游标遍历漏掉最后一条、UPDATE 影响行数为 0 却没做任何处理。这时要主动检查执行结果，而不是等报错：
- 在关键
UPDATE/DELETE后立即加GET DIAGNOSTICS ROW_COUNT = @rowcount;，再用IF @rowcount = 0 THEN SELECT 'WARNING: no rows affected' AS debug_msg; - 对游标循环，强制在
FETCH后检查NOT FOUND状态，而非依赖循环体结束判断 - 用
DECLARE CONTINUE HANDLER FOR SQLSTATE '02000'捕获游标结束，避免因忘记设标志位导致无限循环
逐行打印输出的替代方案：临时调试表 + 时间戳标记
直接 SELECT 不仅干扰流程，还难追溯执行顺序。更可靠的做法是统一写入带时间戳的调试表：
- 建表语句必须含
log_time DATETIME(6) DEFAULT CURRENT_TIMESTAMP(6)，微秒级精度才能区分快速连续操作 - 每步插入用
INSERT INTO debug_log (message, value_info) VALUES ('step_3_check_balance', CONCAT('user_id=', @uid, ', balance=', @balance)); - 查询时加
ORDER BY log_time，一眼看出哪步被跳过、哪步重复执行、哪步耗时异常
最易被忽略的是：调试表本身必须在事务外操作（显式 START TRANSACTION 后不包含它），否则回滚会把日志也删掉——你永远看不到失败那一刻发生了什么。
