子查询匹配区间时不能用=或IN，因为=要求标量子查询（单行单列），IN仅支持离散值匹配；而区间判断需用BETWEEN或>= AND <=表达连续范围。
子查询匹配区间时为什么不能用 = 或 IN
因为区间匹配本质是「某个值落在某段范围内」，不是「等于某个离散值」。用 = 会报错（子查询返回多行），IN 只能判断是否属于一组明确值，无法表达 BETWEEN 或 >= AND 这类连续逻辑。真正可行的是把子查询放在 <code>WHERE 的条件表达式里，让它返回布尔结果或参与比较运算。
用 EXISTS + 相关子查询做存在性区间判断
这是最常用也最安全的方式：外层查主表记录，内层用相关子查询检查是否存在满足区间条件的对照表记录。数据库可以高效利用索引，且天然避免重复匹配问题。
常见错误现象：Subquery returns more than 1 row —— 如果误用了 = 或标量子查询却没加 LIMIT 1 或聚合，就会触发这个错误。
- 必须在子查询
WHERE中引用外层表字段（如t1.amount），构成相关子查询 - 子查询只需返回任意一行即可，用
EXISTS语义最清晰，不关心具体值 - 对照表的区间字段（如
min_val/max_val）建议建复合索引：(min_val, max_val)
SELECT t1.order_id, t1.amount
FROM orders t1
WHERE EXISTS (
SELECT 1 FROM discounts d
WHERE t1.amount >= d.min_val AND t1.amount < d.max_val
AND d.status = 'active'
);
用标量子查询配合 CASE 或直接赋值做单值映射
当每个主表记录**最多只匹配一个区间**（比如税率档位、会员等级），可用标量子查询返回唯一值。但必须确保子查询最多返回一行，否则运行时报错。
性能影响：如果子查询无法走索引，或外层数据量大，可能比 JOIN 慢很多；但逻辑隔离性强，适合业务规则频繁变动的场景。
- 用
(SELECT ... LIMIT 1)是兜底写法，但掩盖了数据设计问题 - 更稳妥的是用聚合函数兜住，例如
MAX(d.rate)，前提是业务允许取极值 - 若区间有重叠且需优先级（如高优先级规则排前面），得在子查询里加
ORDER BY priority DESC LIMIT 1
SELECT
order_id,
(SELECT d.discount_rate
FROM discount_rules d
WHERE o.total_amount BETWEEN d.min_amt AND d.max_amt
AND d.enabled = 1
ORDER BY d.priority DESC
LIMIT 1) AS rate
FROM orders o;
容易被忽略的边界与 NULL 风险
区间字段为 NULL 时，整个条件表达式结果为 UNKNOWN，该行会被过滤掉——这和直觉不符，尤其当默认值设为 NULL 时极易漏数据。
另一个隐形坑是开闭区间不一致：比如一张表用 BETWEEN a AND b（闭区间），另一张用 >= a AND （左闭右开），混用会导致边界值匹配失败。
- 所有区间字段都应设
NOT NULL约束，或在子查询中显式排除IS NULL - 统一使用
>= AND 更可控，避免 <code>BETWEEN在时间字段上因秒级精度丢失末尾值 - 测试时务必覆盖边界值：刚好等于
min_val、刚好等于max_val、刚好跨区间临界点
实际写的时候，别指望子查询自动处理重叠或空隙——匹配逻辑是刚性的，差 0.01 元、少 1 秒、null 多一个，结果就可能完全不同。
