ORA-01403 错误本质是 SELECT ... INTO 未返回任何行，因该语句要求必须且仅返回一行；NVL/COALESCE 无效，需用聚合函数、DUAL 子查询或异常处理主动应对。
ORA-01403 错误本质是 SELECT ... INTO 语句没查到任何行，不是 NULL 值问题，而是空结果集导致赋值失败。必须主动处理，不能靠 NVL 或 COALESCE 拦截。
为什么 SELECT ... INTO 会报 ORA-01403
Oracle 的 SELECT ... INTO 是隐式单行查询，要求**必须且只能返回一行**。哪怕表里有数据，但 WHERE 条件不匹配、拼写错误、大小写敏感（如 VARCHAR2 字段）、或数据被事务隔离（如未提交的 INSERT），都会触发该错误。
常见误判点：
-
NVL(t_id, 0)对 ORA-01403 无效 —— 它只处理已返回但为 NULL 的值，而这里根本没返回任何行 -
ROWNUM = 1也不能保底：如果全表无匹配记录，ROWNUM还没机会生效就已空集 - 在函数或过程里直接调用，没加
EXCEPTION块，错误会直接中断执行流
用聚合函数兜底：推荐 MIN() 或 COUNT(*)
聚合函数天然支持空集：没数据时返回 NULL（MIN/MAX/SUM）或 0（COUNT(*)），不会抛异常，适合做“存在性探测”或“安全取值”。
示例场景：查用户最新订单 ID，允许为空
DECLARE
v_order_id NUMBER;
BEGIN
-- ✅ 安全：没数据时 v_order_id = NULL，不报错
SELECT MIN(order_id) INTO v_order_id
FROM orders
WHERE user_id = 123
AND status = 'SHIPPED'
ORDER BY created_date DESC;
<p>IF v_order_id IS NOT NULL THEN
-- 后续逻辑
END IF;
END;注意：
-
MIN()和MAX()在空集时返回 NULL；COUNT(*)返回 0，适合判断是否存在 - 避免用
SUM()处理主键类字段 —— 若字段为 NULL，SUM仍返回 NULL，语义易混淆 - 不要混用
ORDER BY和聚合函数：Oracle 不保证MIN(order_id)对应的是最新创建的那条，需确认业务是否真需要“最小 ID”而非“最新 ID”
用 DUAL + 子查询避免重复扫描
当原 SQL 较复杂（含 JOIN、子查询、函数等），先 COUNT(*) 再查一遍会扫描两次表，性能差。用 DUAL 包裹子查询，一次执行、安全赋值。
单字段示例：
SELECT (SELECT emp_name FROM employees WHERE emp_no = 9999) INTO v_name FROM DUAL;
多字段示例：
WITH src AS (
SELECT name, dept_id, salary
FROM employees e
JOIN departments d ON e.dept_id = d.id
WHERE e.emp_no = 9999
)
SELECT NVL((SELECT name FROM src), 'N/A'),
NVL((SELECT dept_id FROM src), -1),
NVL((SELECT salary FROM src), 0)
INTO v_name, v_dept_id, v_salary
FROM DUAL;关键点：
- 子查询为空时，
(SELECT ...)返回 NULL，NVL才起作用 —— 这和直接NVL在SELECT ... INTO外层不同 -
WITH子句确保复杂逻辑只执行一次，比先COUNT再查更高效 - 所有字段必须显式用
NVL或COALESCE提供默认值，否则任一字段为 NULL 都可能导致后续逻辑出错
异常捕获不是万能解法
EXCEPTION WHEN NO_DATA_FOUND THEN 能防止中断，但容易掩盖真实问题 —— 比如本该存在的配置项缺失，捕获后设默认值可能让系统行为偏离预期。
适用场景有限：
- 明确接受“无数据即跳过”的分支逻辑（如可选参数校验）
- 兜底日志记录，但不替代数据治理（例如：查不到客户等级，记录告警并设为“普通”，而非静默忽略）
- 嵌套块中局部处理，避免影响外层事务一致性
反模式示例：
BEGIN
SELECT config_value INTO v_val FROM sys_config WHERE key = 'timeout';
EXCEPTION
WHEN NO_DATA_FOUND THEN
v_val := '30'; -- ❌ 配置缺失本应报警，而非硬编码默认值
END;真正麻烦的不是语法怎么写，而是得想清楚：这条 SELECT ... INTO 查不到数据，到底是代码逻辑缺陷、数据状态异常，还是业务规则本就允许缺省？把“怎么不报错”变成“为什么不该报错”，才能避开最深的坑。
