标量子查询逻辑读暴增的根本原因是其被当作关联子查询执行：外层每扫一行，内层就重复执行一次且不走索引，导致逻辑读=外层行数×内层单次逻辑读；判断依据是执行计划中出现DEPENDENT SUBQUERY或Correlated Subquery标记。
标量子查询没走索引，为什么逻辑读暴增？
根本原因不是“子查询本身慢”，而是它被当作关联子查询执行了——外层每扫一行，内层就重新执行一次，且每次都不走索引。逻辑读 = 外层扫描行数 × 内层单次执行的逻辑读，很容易从几百飙到几十万。
怎么判断是不是关联子查询在反复执行？
看执行计划里子查询节点是否带 DEPENDENT SUBQUERY（MySQL）或 Correlated Subquery（Oracle/SQL Server）。只要出现这个标记，就说明它依赖外层字段，无法物化，只能逐行调用。
- 检查子查询中是否引用了外层表的列，比如
WHERE t2.id = t1.parent_id - 确认子查询是否出现在
SELECT列表里（最危险的位置），而不是WHERE或FROM - 注意 Oracle 中
ROWNUM = 1+ 关联条件的写法，极易触发非预期的逐行执行
为什么明明有索引，标量子查询还是不走？
常见原因不是索引不存在，而是索引无法覆盖查询路径。例如：
- 子查询里用了函数：如
TO_NUMBER(t2.code)，导致索引失效 - 存在隐式类型转换：外层是
VARCHAR2，子查询条件却用数字比较，触发全表扫描 - 索引字段顺序不匹配：子查询条件是
WHERE a = ? AND b > ?，但索引建的是(b, a)，最左前缀不生效 - 统计信息过期：优化器误判为“小表”，选择嵌套循环+全表扫描而非索引查找
替代方案比强行索引更有效
与其花时间调索引让标量子查询“勉强走”，不如换执行模型——把重复计算变成一次物化。
- 用
LEFT JOIN+ 聚合/窗口函数替代：把子查询逻辑上提，避免逐行触发 - 改写为
LATERAL（PostgreSQL）或APPLY（SQL Server），明确控制执行时机和物化行为 - 对高频使用的标量值，提前预计算进临时表或物化视图，用主键关联代替运行时计算
真正卡住性能的，往往不是“有没有索引”，而是“执行计划是否允许索引被复用”。标量子查询一旦陷入 DEPENDENT SUBQUERY 模式，再好的索引也救不了逐行回表的开销。
