非相关子查询仅执行一次且可独立运行，常用于where、select或having中，不引用外部表列；数据库会物化其结果以提升性能，但结果集过大仍会拖慢响应。
非相关子查询本身不提高速度，它只是“不拖慢”——只要写得对，它只执行一次，不会像相关子查询那样每行都重算。
非相关子查询的典型位置和写法
它最常出现在 WHERE、SELECT 列表或 HAVING 中，且内部不引用外部表的任何列。关键判断标准就一条：把子查询单独拿出来运行，能不能不报错、能出结果？能，就是非相关。
-
WHERE salary > (SELECT AVG(salary) FROM employees)✅ 独立可执行 -
SELECT name, (SELECT COUNT(*) FROM departments) AS dept_count FROM employees✅ 子查询无参数，结果对所有行都一样 -
WHERE id IN (SELECT user_id FROM logs WHERE status = 'error')✅ 只要logs表存在，子查询就能跑通
为什么它比相关子查询快得多
数据库优化器对非相关子查询通常会做物化（materialization）：先执行一次，把结果存进临时内存结构或物化中间结果集，后续直接复用。这避免了 N 行 × N 次扫描的灾难。
- 主查询返回 10 万行？子查询仍只执行 1 次
- 如果子查询含
GROUP BY或聚合，结果集大小直接影响内存占用，但跟主表行数无关 - 注意：若子查询返回上百万行（比如
SELECT * FROM huge_log_table），即使只执行一次，也会卡在物化阶段，反而拖累整体响应
容易被误判为“非相关”的坑
表面看没引用外部列，实际可能隐式依赖——尤其是别名、作用域嵌套或数据库方言特性导致的歧义。
- 错误示例：
SELECT e.name, (SELECT AVG(salary) FROM employees WHERE department_id = e.department_id) FROM employees e❌ 这是相关子查询，e.department_id是外部引用，哪怕你没意识到 - 别名污染：子查询里用了和外部表同名的表别名（如都叫
e），可能让优化器误判作用域 - MySQL 5.7 之前，某些带
ORDER BY+LIMIT的子查询会被强制当成相关处理，即使逻辑上独立
真正影响性能的关键不是“是不是非相关”，而是“结果集是否可控”
很多人盯着“非相关”三个字猛夸，却忽略一个事实：一个返回 50 万行的非相关子查询，配合主查询的 IN，很可能触发全索引扫描甚至临时表排序；而一个精简的、带索引字段过滤的相关子查询（配合 EXISTS），有时反而更快。
- 优先给子查询加
WHERE条件缩小结果集，比如(SELECT user_id FROM logs WHERE created_at > '2026-01-01') - 避免在
SELECT列表中放非相关子查询返回多行或多列（如(SELECT id, name FROM users LIMIT 1)），多数数据库会报错或只取第一行，行为不可靠 - 如果子查询结果固定且高频使用，考虑建物化视图或缓存到应用层，而不是每次 SQL 都查一遍
