ora-01422 是 select into 语义错误，因结果集非且仅一行而触发；根本原因是数据重复或条件不精确，需通过聚合、校验、异常捕获或游标等健壮方式处理，而非简单加 rownum=1。
ora-01422 错误本质是 select into 语句的契约被打破：它只接受且仅能处理一行。不是性能问题，而是语义错误。
为什么 SELECT INTO 会触发 ORA-01422
Oracle 在执行 SELECT ... INTO 时，底层使用的是「精确提取（exact fetch）」模式——它预设结果集必须严格为 1 行。只要实际返回 0 行（抛 NO_DATA_FOUND）或 ≥2 行（抛 TOO_MANY_ROWS），就会中断执行流。
常见诱因包括：
- 查询条件基于非唯一字段（如
name、status、config_key），而数据中存在重复值 - 忽略业务上下文，例如未加
AND effective_date 或 <code>AND is_active = 'Y' - 动态拼接 SQL 时，参数未做转义或约束，导致
LIKE匹配过宽（如WHERE c_ahpx LIKE '%'||xyrbh||'%'） - 函数参数名与表列名冲突（如
userno既是参数又是列名），导致谓词恒真，全表扫描
不推荐的“快捷解法”：直接加 ROWNUM = 1
用 AND ROWNUM = 1 强制截断看似简单，但掩盖了根本问题：
- 隐式丢弃其他合法行，可能造成业务逻辑偏差（比如取到旧配置而非最新版）
- 绕过数据质量校验，让重复数据在系统中持续沉淀
- ORDER BY 必须放在子查询内，否则
ROWNUM截取无序结果，不可控
正确写法示例（带排序保障）：
SELECT salary INTO v_sal FROM (SELECT salary FROM emp WHERE name = '张三' ORDER BY hire_date DESC) WHERE ROWNUM = 1;
但请优先考虑下一条方案。
推荐做法：用聚合或显式异常捕获暴露问题
真正健壮的处理，是把「不确定性」变成「可决策行为」：
- 若业务上允许任一值（如取最大/最小/平均），改用
MAX(salary)、MIN(created_time)等聚合函数，天然单值 - 若必须唯一，应在查询前加校验：
SELECT COUNT(*) INTO v_cnt FROM ...，再分支处理 - 若需人工介入，显式捕获
TOO_MANY_ROWS并抛出自定义错误：RAISE_APPLICATION_ERROR(-20001, '员工姓名重复，请用ID查询') - 若调用方能容忍空值，同时捕获
NO_DATA_FOUND并设默认值（如v_sal := 0）
当确实要返回多行时，别硬塞进 SELECT INTO
如果原始需求本就是查一批记录（比如日志列表、配置集合），SELECT INTO 从设计上就不适用：
- 改用显式游标（
OPEN ... FOR）配合SYS_REFCURSOR输出，由应用层消费 - 或用
BULK COLLECT INTO批量加载至 PL/SQL 集合，再循环处理 - 切勿在循环里反复写
SELECT ... INTO——这是 N+1 查询反模式，性能和稳定性双崩
最易被忽略的一点：ORA-01422 往往不是孤立错误，而是上游数据治理缺失的信号。修复语句只是止痛，确认为何会出现重复匹配，才是根治关键。
