子查询中用GETDATE()或NOW()报错主因是返回多行而非单值，正确做法是加TOP 1/LIMIT 1、用聚合函数或CTE预计算；关联子查询需确保关联条件完整；空结果导致UNKNOWN需用COALESCE或EXISTS处理。
子查询里用 GETDATE() 或 NOW() 为什么总报错？
直接在 WHERE 子句的子查询中调用时间函数（如 SQL Server 的 GETDATE()、MySQL 的 NOW()）本身不报错，但常见问题出在「子查询返回多行却用于单值比较」。比如写成：
WHERE order_date > (SELECT DATEADD(day, -30, GETDATE()) FROM orders)——这里子查询会为每行
orders 都算一次，返回多行，而 > 左侧只接受单个标量值。
正确做法是确保子查询返回单一行、单一个值：
- 显式加
TOP 1（SQL Server）或LIMIT 1（MySQL/PostgreSQL） - 用聚合函数兜底，如
MAX(GETDATE())（虽冗余但安全） - 更推荐：把动态日期逻辑提到外层或用 CTE 预计算
用子查询定义动态区间边界，避免硬编码日期
想统计「最近 30 天内下单、但发货延迟超过平均值的订单」，不能写死 '2024-05-01'。可行结构是让子查询先算出基准日期：
SELECT COUNT(*)<br>FROM orders<br>WHERE order_date >= (SELECT DATEADD(day, -30, GETDATE()))<br> AND ship_delay > (SELECT AVG(ship_delay) FROM orders WHERE order_date >= DATEADD(day, -30, GETDATE()))
注意两点：
- 两个子查询里的日期逻辑必须一致，否则统计口径错位；建议抽成 CTE 或变量（如 SQL Server 的
@start_date = DATEADD(day, -30, GETDATE())） - MySQL 中
DATE_SUB(NOW(), INTERVAL 30 DAY)是等效写法，别混用函数名 - PostgreSQL 用
CURRENT_DATE - INTERVAL '30 days'，子查询中直接写即可，无需额外封装
关联子查询中动态计算每个用户的活跃窗口
当需要「对每个用户分别取其最近一次下单日往前推 7 天作为活跃区间」，就得用关联子查询：
SELECT u.user_id,<br> COUNT(o.order_id) AS recent_orders<br>FROM users u<br>LEFT JOIN orders o ON o.user_id = u.user_id<br> AND o.order_date >= (<br> SELECT MAX(o2.order_date) - INTERVAL '7 days'<br> FROM orders o2<br> WHERE o2.user_id = u.user_id<br> )<br>GROUP BY u.user_id
这个结构容易卡慢，关键点：
- 子查询中的
WHERE o2.user_id = u.user_id是关联条件，缺了就变成全表扫描 - MySQL 8.0+、PostgreSQL 支持窗口函数，此时用
MAX(order_date) OVER (PARTITION BY user_id)替代子查询，性能提升明显 - SQL Server 中若用
DATEADD(day, -7, MAX(order_date))，需确保子查询返回非 NULL；可加ISNULL(..., '1970-01-01')防空值中断
子查询返回空结果时，整个条件变成 UNKNOWN 而非 FALSE
这是最隐蔽的坑：
WHERE order_date > (SELECT MIN(order_date) FROM orders WHERE status = 'cancelled')如果子查询没找到已取消订单，返回
NULL，那么整个表达式变成 order_date > NULL → 结果为 UNKNOWN，该行被过滤掉——即使它本应满足其他条件。
修复方式只有两种：
- 显式处理 NULL：
WHERE order_date > COALESCE((SELECT MIN(...)), '1900-01-01') - 改用
EXISTS+ 关联逻辑，把「依赖子查询结果」转为「存在性判断」，语义更清晰且 NULL 安全
