在分析“MySQL 存储过程中 Num 总是输出 0：TempSno 没有默认值的根本原因与排查思路”的问题时，核心在于理解 OUT 参数的赋值路径、TempSno 的默认值状态，以及 COUNT(...) 或 EXISTS 的返回值如何影响 Num 的最终值。
问题现象与背景
Num 总是输出 0 的常见表现
在很多场景中，外部调用存储过程时，Num 作为 OUT 参数，总是返回 0，即使你在过程中通过 SQL 计算期望得到非零结果。这种现象常常导致分析迷惑，需要确认赋值路径是否覆盖了所有分支，以及是否有 NULL 值干扰结果。
另一个关键点是你可能把 TempSno 没有默认值 的状态混入逻辑中，导致某些分支安全路径没有对 Num 赋值。这种情况在分支错综复杂的存储过程中特别常见。
请记住，存储过程中的 OUT 参数在没有被显式赋值时，最终结果取决于实现与版本，某些场景下仍会回落为 0，从而掩盖实际计算结果。
TempSno 没有默认值的潜在影响
TempSno 作为输入参数若没有默认值或传入 NULL 时，往往导致 WHERE 条件无法命中，进而使统计量为 0，影响 Num 的最终值。
此外，TempSno 的默认处理与数据类型强制也会对分支走向和结果产生影响，导致某些路径从未进入写回 Num 的阶段。
根本原因分析
OUT 参数未被所有分支赋值
如果在某些分支里没有明确给 OUT 参数赋值，最终输出的值就可能保持初始值，如 0。这是最常见的根本原因之一。
在设计存储过程时，务必把每条逻辑分支都覆盖到赋值操作，否则调用端得到的 Num 可能与期望不符。
TempSno 没有默认值导致的影响
TempSno 作为用于筛选的条件，如果在调用端未传入有效值或者内部没有对 NULL 做处理，查询可能返回 0 行，从而把 Num 的赋值滞后或变成 0。
因此，缺省的 TempSno 处理会成为导致 Num 始终输出 0 的一个隐蔽源头，尤其是在输入参数边界条件复杂的场景。
聚合与存在性判断的陷阱
常见的实现中，开发者使用 COUNT(*)、SUM(...)、EXISTS(…) 等 来为 Num 赋值。若表中没有匹配行，COUNT 会返回 0，自然 Num 变为 0；如果你依赖的不是计数而是存在性判断，也可能导致误判。
因此需要区分“找到了数据”和“没找到数据”两种情况，并为这两种情况制定明确的默认值策略，以及覆盖所有分支的赋值逻辑。
排查思路与步骤
快速复现与日志记录
第一步是把 OUT 参数的赋值路径可视化，可以在存储过程中增加临时变量或日志输出，确保在任意分支后 Num 的值都有可见的输出。
实践要点：在关键分支后添加赋值，或通过 SELECT ... INTO Num 的方式直接写回。
分步调试与最小化重现
将复杂的存储过程拆解为最小可重现的版本，逐步验证 TempSno、WHERE 条件和 COUNT/EXISTS 的返回结果是否符合预期。
对于每次调用，先单独测试 TempSno 是否能带来非 0 的数量，再验证 OUT 参数 Num 的赋值逻辑是否覆盖所有分支。
引入默认值与健壮性处理
为 IN 参数添加合理的默认值，或在过程开始处对 TempSno 进行 NULL 或无效值判断，是提升健壮性的关键方法。
通过显式覆盖默认路径，可以避免在部分分支中 Num 保持为初始值的情况。
代码示例与修复策略
问题示例：Num 赋值路径未覆盖
下面的示例展示了一个最简单的情形：Num 初始化为 0，然后仅在存在匹配行时才重新赋值。若没有匹配行，Num 将保持为 0。
DELIMITER //
CREATE PROCEDURE GetNum_Q1(IN TempSno INT, OUT Num INT)
BEGIN
-- 直接初始化
SET Num = 0;
-- 只在匹配时更新
SELECT COUNT(*) INTO Num
FROM t_sno
WHERE sno = TempSno;
END //
DELIMITER ;
要点：这种默认初始化为 0 的写法虽然简单，但要确保在每个分支都能写回一个非 0 的值，或者在调用方对结果进行后续处理以避免误解。
修复示例：确保在各分支都赋值并处理 NULL
下面的修复版本通过显式处理 NULL，并在无效输入时给出明确的 0，确保 Num 的行为可预测。
DELIMITER //
CREATE PROCEDURE GetNum_Q2(IN TempSno INT, OUT Num INT)
BEGIN
-- 处理 NULL 输入
IF TempSno IS NULL THEN
SET Num = 0;
RETURN;
END IF;
-- 重新计算并写回输出参数
SELECT COUNT(*) INTO Num
FROM t_sno
WHERE sno = TempSno;
END //
DELIMITER ;
如果需要更严格的默认策略，可以考虑在参数定义处使用默认值（若你的 MySQL 版本支持），或在调用端提供明确的传入值。
