非关联子查询本身只执行一次，真正需警惕的是误判为非关联实则被当作关联执行或物化失败；确认关键看是否引用外层表字段，如 users.id；可用 EXPLAIN 验证物化效果；慢因多为单次执行过重或物化被绕过。
非关联子查询（Non-correlated Subquery）本身就不会重复执行——它只运行一次，这是优化器的默认行为，不是你需要“避免”的问题。真正该警惕的是误判为非关联、实则被当作关联执行，或者物化失败导致逻辑上单次但物理上多次扫描。
怎么确认子查询真是非关联的
关键看它是否引用外层表字段。只要出现 users.id、o.user_id 这类带点号的列名，哪怕只写错一个字母，它就是相关子查询，必然逐行重跑。
- 把子查询整段复制出来，单独
SELECT一把：不报Unknown column错、能出结果 → 基本是非关联 -
EXPLAIN FORMAT=TREE（MySQL 8.0+）里看到-> Materialize包裹 → 确认被物化，只执行一次 - PostgreSQL 用
EXPLAIN (ANALYZE, VERBOSE)，看子查询的actual time是否稳定且只出现一次
为什么“非关联”子查询还是慢了
慢不是因为重复执行，而是单次执行太重，或物化机制被绕过。
-
NOW()、RAND()、用户变量@var出现在子查询里 → 优化器认为结果不可复用，每次都会重算 - 子查询含
LIMIT但没ORDER BY→ MySQL 可能拒绝物化（结果不稳定） - 返回结果集过大（比如
SELECT * FROM huge_log_table）→ 物化过程卡在内存分配或落盘，拖慢整体响应 - MySQL 5.7 或更早版本对某些带聚合的子查询会退化为内联展开，失去物化机会
强制物化的实操手段
别依赖优化器猜，显式告诉它“必须只跑一次”。
- PostgreSQL：用
WITH active_users AS MATERIALIZED (SELECT id FROM users WHERE status = 'active')，后面直接引用active_users - MySQL 8.0.22+：加优化器提示
SELECT /*+ MATERIALIZE() */ * FROM orders WHERE user_id IN (SELECT id FROM users WHERE ...) - 通用兜底：把子查询提成 CTE（即使不加
MATERIALIZED），多数引擎也会倾向物化，比裸子查询更可控
最容易被忽略的陷阱
很多人盯着“非关联”三个字就放心了，却忘了检查子查询内部是否真干净。
- 别名冲突：子查询里也用了和外层一样的表别名（比如都叫
e），可能让优化器误判作用域，悄悄转成相关 - 隐式类型转换：子查询返回
VARCHAR，外层比较用INT→ 触发全表转换，物化失效 - WHERE 条件没过滤数据：
(SELECT user_id FROM logs)比(SELECT user_id FROM logs WHERE created_at > '2026-01-01')更容易压垮物化阶段
