子查询不能直接引用外部查询别名字段，非相关子查询独立执行且只计算一次；需用相关子查询（加关联条件）或窗口函数（如min() over(partition by...)）实现动态分组计算，后者更高效。
子查询里不能直接用外部查询的别名时间字段
很多人写 WHERE date_col BETWEEN (SELECT MIN(date_col) FROM t2) AND (SELECT MAX(date_col) FROM t2) 时，想让它自动对齐主查询的某条记录的时间范围，结果发现子查询完全独立执行，根本拿不到外层行的上下文。这是最常见的误解——SQL 标准中，非相关子查询（即不带 WHERE 关联外层表的子查询）永远只算一次，返回固定值。
真正能“动态”的，是相关子查询，必须显式关联。比如你想对比每条订单的下单时间与它所属用户的历史首末单时间：
SELECT order_id, order_time, (SELECT MIN(order_time) FROM orders o2 WHERE o2.user_id = o1.user_id) AS user_first_order, (SELECT MAX(order_time) FROM orders o2 WHERE o2.user_id = o1.user_id) AS user_last_order FROM orders o1;
- 关键在子查询里的
o2.user_id = o1.user_id—— 这个等号把子查询和当前行绑定了 - 没这个条件，子查询就变成全局统计，所有行看到的都是全表的 MIN/MAX
- 性能上，这种写法在大表上会明显变慢，因为每行都要触发两次独立扫描
用窗口函数替代嵌套子查询更高效
如果只是想获取同组内的时间极值（比如每个用户最早/最晚订单时间），MIN() OVER (PARTITION BY user_id) 比相关子查询快得多，且语义更清晰。
SELECT order_id, order_time, MIN(order_time) OVER (PARTITION BY user_id) AS user_first_order, MAX(order_time) OVER (PARTITION BY user_id) AS user_last_order FROM orders;
- 窗口函数只扫描一次表，内部按
PARTITION BY分组聚合，无重复计算 - 不支持在
WHERE或HAVING中直接使用窗口函数结果（会报错invalid use of window function），得套一层子查询或 CTE - MySQL 8.0+、PostgreSQL、SQL Server 2012+ 都支持；SQLite 3.25+ 也支持，但旧版不兼容
跨时间区间对比必须用 JOIN 或 LATERAL（PostgreSQL）
当你要查“某个订单时间是否落在该用户过去 7 天活跃期内”，就不能只靠标量子查询——需要把时间区间当成一个可 join 的实体。这时相关子查询力不从心，容易写出逻辑错误。
推荐写法（以 PostgreSQL 为例，用 LATERAL）：
SELECT
o1.order_id,
o1.order_time,
active_window.start_time,
active_window.end_time
FROM orders o1
LATERAL (
SELECT
MAX(o2.order_time) - INTERVAL '7 days' AS start_time,
MAX(o2.order_time) AS end_time
FROM orders o2
WHERE o2.user_id = o1.user_id
AND o2.order_time
-
LATERAL允许右侧子查询引用左侧表字段，且对每一行重新执行 - 注意子查询里的
o2.order_time ：限定“截至当前订单时刻”的历史数据，否则区间会漂移 - MySQL 不支持
LATERAL，得用 JOIN + 聚合子查询模拟，但需小心 NULL 和多行问题
WHERE 中嵌套子查询返回多行会直接报错
写类似 WHERE order_time IN (SELECT date_col FROM calendar WHERE is_workday = true) 是安全的，但一旦子查询可能返回空或多于一行，而你又把它放在标量上下文中（比如 = 左右），就会触发 Subquery returns more than 1 row 或 Subquery returns no rows 错误。
- 用
IN/EXISTS替代=可规避多行问题 - 用
COALESCE((SELECT ...), '1970-01-01')可兜底空结果，但要确认默认值在业务逻辑中合理 - MySQL 中
SELECT ... FROM t1 WHERE col = (SELECT col FROM t2 LIMIT 1)看似能绕过，但语义已丢失，不推荐
动态时间区间的核心从来不是“怎么写嵌套”，而是“要不要真嵌套”——多数场景下，窗口函数或预计算区间表更稳，相关子查询只适合逻辑简单、数据量小、且必须逐行判断的情况。
