MySQL 5.7及更早版本不支持BETWEEN右侧使用标量子查询，因BETWEEN要求左右操作数均为严格单行单列值；应改用>=和
WHERE子句里用BETWEEN套子查询结果会报错
直接写 WHERE date_col BETWEEN (SELECT min_date FROM config) AND (SELECT max_date FROM config) 在多数数据库（如 PostgreSQL、SQL Server）中是合法的，但 MySQL 5.7 及更早版本不支持在 BETWEEN 右侧使用标量子查询——会报错 ERROR 1242: Subquery returns more than 1 row 或语法错误。根本原因不是“不能嵌套”，而是 BETWEEN 要求左右操作数都是单值，而子查询若未明确限制为标量（即 1 行 1 列），优化器可能无法推断其确定性。
- 务必确保子查询返回**严格单行单列**：加
LIMIT 1不够安全，应配合WHERE条件或聚合（如MIN()/MAX()）保证唯一性 - MySQL 用户可改用
>=和拆解：<code>WHERE date_col >= (SELECT min_date FROM config) AND date_col - PostgreSQL 允许
BETWEEN直接接子查询，但若子查询无结果（返回 NULL），整个条件判为 UNKNOWN，该行被过滤——这点常被忽略
子查询返回多行时用IN或EXISTS替代BETWEEN
如果配置表存的是多个有效日期区间（比如按业务线分片），而你想查落在**任一区间内**的记录，就不能用 BETWEEN 套单个子查询——它只接受两个端点。此时必须换思路。
- 用
EXISTS关联区间表：WHERE EXISTS (SELECT 1 FROM date_ranges r WHERE t.date_col BETWEEN r.start_date AND r.end_date) - 避免用
IN配合SELECT date_val FROM dates_list，因为IN只支持离散值，无法表达“范围”语义 - 注意
EXISTS中的BETWEEN仍需确保r.start_date和r.end_date非 NULL；否则加AND r.start_date IS NOT NULL AND r.end_date IS NOT NULL
动态日期范围依赖当前时间时，别硬写子查询
比如“查最近30天的数据”，有人写 (SELECT CURRENT_DATE - INTERVAL '30 days') 和 (SELECT CURRENT_DATE) 作为子查询端点。这不仅冗余，还可能因执行计划缓存导致日期冻结（尤其在物化视图或某些 ORM 中）。
- 直接用表达式：
WHERE date_col BETWEEN CURRENT_DATE - INTERVAL '30 days' AND CURRENT_DATE（PostgreSQL/MySQL 8.0+） - SQL Server 用
DATEADD(day, -30, GETDATE())，别封装进子查询 - 若必须复用（如多个字段都要比对同一动态范围），用 CTE 提前算好：
WITH date_range AS (SELECT CURRENT_DATE - INTERVAL '30 days' AS start_d, CURRENT_DATE AS end_d) SELECT * FROM t JOIN date_range r ON t.date_col BETWEEN r.start_d AND r.end_d
性能陷阱：BETWEEN + 子查询可能让索引失效
当子查询结果不可知（如依赖参数或运行时变量），优化器常放弃使用 date_col 上的索引，转为全表扫描。特别是子查询涉及函数或关联其他大表时。
- 先确认执行计划：在 PostgreSQL 用
EXPLAIN，MySQL 用EXPLAIN FORMAT=TREE，看是否出现Index Scan或range访问类型 - 把子查询结果提前算出并绑定为参数（如应用层传入
start_date和end_date），比让数据库每次执行时重算更可靠 - 若子查询来自小表（/*+ USE_INDEX(config idx_config_dates) */ 类提示（依数据库支持情况）
真正麻烦的不是语法怎么写，而是子查询的执行时机和优化器能否推导出范围边界——这两点决定了查询是毫秒级还是分钟级。
