ora-01403是pl/sql中select into语句未返回任何行时触发的no_data_found异常，本质是语言强制要求对空结果集显式处理，而非程序崩溃；其设计约束在于赋值动作必须获得确定值，聚合函数因默认返回null或0故不报错，而nvl等转换逻辑在取值失败前无法执行。
ora-01403 不是程序崩溃，而是 pl/sql 对空结果集的明确拒绝 —— 它要求你主动决定“查不到时该怎么办”，而不是默认跳过。
为什么 SELECT ... INTO 一查不到就报错
Oracle 的 SELECT ... INTO 语义是“必须且只能返回一行”。它不是普通查询，而是赋值动作：目标变量要接收一个确定的值。当 WHERE 条件不匹配任何行时，没有值可赋，PL/SQL 就抛出 NO_DATA_FOUND 异常（对应错误码 ORA-01403）。这不是 bug，是设计约束。
- 聚合函数如
SUM()、COUNT()即使无数据也返回NULL或0，所以SELECT SUM(x) INTO v FROM t WHERE 1=0不会报错 - 但
SELECT x INTO v FROM t WHERE 1=0一定报 ORA-01403 —— 因为x没有值可提供 -
NVL(x, 0)在这种场景下无效：异常发生在“取值”阶段，根本没走到“转换”环节
用 EXCEPTION 块捕获 NO_DATA_FOUND 是最直接的做法
在可能出问题的 SELECT ... INTO 外层加一个独立的 BEGIN ... EXCEPTION ... END 块，把异常控制在局部，避免中断整个循环或事务。
- 不要把整个存储过程包在一个大
EXCEPTION里，否则错误位置难定位 - 推荐写法：
BEGIN SELECT col1 INTO v_val FROM t WHERE id = p_id; EXCEPTION WHEN NO_DATA_FOUND THEN v_val := NULL; -- 或设默认值，如 0、'N/A' END; - 如果后续逻辑依赖该变量是否被赋值，可以用
v_val IS NULL判断，但注意区分“查到 NULL”和“根本没查到”——后者你已显式设了默认值，语义就清晰了
别用 SELECT COUNT(*) 预检，除非真需要计数
先 SELECT COUNT(*) INTO v_cnt FROM ... 再判断是否 > 0，接着再执行真正的 SELECT ... INTO —— 这看似稳妥，实则引入两次全表扫描（或索引查找），性能开销翻倍，且在并发环境下存在竞态风险（两次查询之间数据可能被删）。
- 仅当业务本身就需要知道“是否存在多条匹配记录”时，才值得用
COUNT - 若只是防 ORA-01403，异常处理更轻量、更符合 PL/SQL 习惯
- 某些 ORM 或中间件生成的代码会自动加
COUNT，需人工 review 是否冗余
复杂查询字段多时，DUAL + 子查询是安全替代方案
当你要从同一张表查多个字段，又不想写一堆 EXCEPTION 块，可用 DUAL 包裹子查询。子查询本身允许返回 0 行，DUAL 确保外层总有一行可选。
- 单字段：
SELECT (SELECT name FROM users WHERE id = 123) INTO v_name FROM DUAL;
查不到时v_name得NULL - 多字段（需配合
WITH）：WITH t AS (SELECT name, email FROM users WHERE id = 123) SELECT (SELECT name FROM t), (SELECT email FROM t) INTO v_name, v_email FROM DUAL;
- 注意：子查询不能含
GROUP BY或聚合，否则仍可能因无数据报错；此法适合简单条件查询
真正容易被忽略的是异常范围 —— NO_DATA_FOUND 只能被同一作用域内的 EXCEPTION 捕获。嵌套块里没写 EXCEPTION，异常会向上冒泡，可能跳过你本想执行的 COMMIT 或日志记录。写之前，先想清楚这行查询失败后，逻辑该继续、跳过，还是终止当前循环迭代。
