标量子查询在海量数据下本质是串行执行，因语法强制锁定为嵌套循环模型：主表每行触发一次子查询，导致o(n×m)复杂度，无法物化复用，即使有索引也仅加速单次执行而非减少调用次数。
标量子查询在海量数据下本质就是串行执行——不是数据库“选择”串行，而是执行模型被语法锁死为逐行驱动。
标量子查询的执行模型被锁定为嵌套循环
只要子查询里引用了外层表字段（比如 WHERE b.a_id = a.id），数据库就必须对主表每一行都重新执行一遍子查询。这不是优化器偷懒，是语义强制：标量结果必须绑定到当前行上下文，无法提前物化成一张临时表再关联。
- 主表 10 万行 → 子查询触发 10 万次独立执行
- 每次都要走完整流程：解析、计划生成、索引查找（哪怕条件相同）、聚合计算
- 即使
b表有INDEX ON b(a_id, val)，也只加速单次查找，不减少调用次数
为什么不能像 JOIN 那样并行或哈希处理
JOIN 可以把两表各自扫描一次，再用哈希或排序合并；而标量子查询返回的是单值，且语义上要求“这一行的值只能由这一行的条件算出来”，数据库无法跨行复用中间结果。
- 没有
LATERAL（PostgreSQL/Oracle）显式声明时，优化器不敢自动重写为LEFT JOIN - 含
COUNT(*)、SUM()或多表关联的子查询，MySQL 8.0+ 和 Oracle 也大概率放弃重写 - SQL Server 对嵌套在标量位置的 MSTVF 还会强制序列化，进一步堵死并发可能
不相关子查询除外，但容易误判
真正只执行一次的，是**不相关**标量子查询——即子查询里完全没出现外层表列，比如 (SELECT MAX(price) FROM products)。一旦漏删 WHERE t1.id = t2.id 这类引用，就立刻退化为逐行执行。
- 看
EXPLAIN输出：若没有DEPENDENT SUBQUERY提示，说明它被当成常量处理了 - 误写成相关形式后，性能可能从毫秒级暴跌到分钟级，且统计信息难以准确估算代价
最危险的不是语法报错，而是看着能跑通、数据也对，却在 10 万行时悄悄发起 10 万次独立查询——这种隐性串行，比明面上的慢 SQL 更难排查。
