SELECT INTO本质是单行契约，非性能问题而是语义限制：Oracle强制「精确提取」，必须且仅返回1行，否则抛NO_DATA_FOUND或ORA-01422中断执行。
SELECT INTO 本质是单行契约，不是性能问题而是语义限制
SELECT INTO 在 PL/SQL 中效率“低”的错觉，往往来自它被误用在本该返回多行或零行的场景。它根本就不是为批量数据设计的——Oracle 底层强制走「精确提取（exact fetch）」路径，必须且只能返回 1 行。一旦实际结果是 0 行，抛 NO_DATA_FOUND；≥2 行，立刻报 ORA-01422。这不是慢，是直接中断执行流。
常见误用包括：
- 用非唯一字段（如
name、status）作查询条件，而表中存在重复值 - 漏加业务有效性约束，比如没写
AND is_active = 'Y'或AND effective_date - 动态拼接 SQL 时，
LIKE条件过宽（如WHERE c_ahpx LIKE '%'||xyrbh||'%'），导致意外匹配多行 - 参数名与列名同名（如参数
userno和表列userno），谓词恒真，全表扫描
为什么加 ROWNUM = 1 不是优化，而是掩盖问题
很多人看到 ORA-01422 就下意识加 AND ROWNUM = 1，但这不是性能优化，是绕过校验。
它带来的实际风险比“慢”更严重：
- 隐式丢弃其他合法行，例如取到过期配置而非最新版，业务逻辑出错
- 让重复数据持续沉淀，掩盖底层数据质量问题
-
ORDER BY必须放在子查询里才有效；写在外层的ORDER BY对ROWNUM = 1无效，结果不可控 - 即使加了子查询排序，也只解决“取哪一行”，不解决“为什么有多行”
正确写法示例（带确定性排序）：
SELECT salary INTO v_sal FROM (SELECT salary FROM emp WHERE name = '张三' ORDER BY hire_date DESC) WHERE ROWNUM = 1;
真正影响执行效率的，是背后的 SQL 写法和数据访问路径
当 SELECT INTO 真的变慢，根源几乎总在它包裹的那条 SELECT 上，而不是语句本身。Oracle 会为这条语句生成完整执行计划，和普通查询无异。
典型低效原因包括：
- 未给查询条件字段建索引，导致全表扫描（尤其在大表上）
- 用了
SELECT *，触发数据字典解析开销，且传输冗余字段 - 子查询含多表
JOIN但连接列无索引，或驱动顺序不合理 - 写了
WHERE ... IN (SELECT ...)而没改用EXISTS，引发嵌套循环+全扫描 - 函数包裹条件列（如
WHERE UPPER(name) = 'ZHANGSAN'），使索引失效
替代方案比“硬扛 SELECT INTO”更健壮
如果业务上确实可能返回 0 或多行，SELECT INTO 就不该是首选。更合理的做法取决于场景：
- 需要最多一行（如查最新记录）：用带
ROWNUM的子查询，但务必加ORDER BY保证确定性 - 需要处理 0–N 行：改用显式游标（
FOR rec IN (...) LOOP），或BULK COLLECT INTO+ 限行 - 仅需判断是否存在：用
SELECT COUNT(1) INTO v_cnt FROM ... WHERE ...，避免提取实际数据 - 需要聚合结果（如最大值、平均值）：直接用
SELECT MAX(...) INTO ...，天然满足单行契约
关键点在于：不要把 SELECT INTO 当成通用查询工具。它的存在意义是“我明确知道且要求只有一行”，一旦这个前提动摇，就得换思路——否则花时间调优，只是在给错误的前提打补丁。
