BETWEEN AND 是闭区间，包含边界值；当 a > b 时返回空结果而非报错或交换顺序；手写 >= 和
WHERE x BETWEEN a AND b 会包含边界值
很多人以为 BETWEEN AND 是“半开区间”，其实它等价于 x >= a AND x ，左右都闭合。比如 <code>age BETWEEN 18 AND 25 会查出 18 岁和 25 岁的人，不是 19–24。
常见错误现象：date BETWEEN '2023-01-01' AND '2023-12-31' 看似查全年，但如果 date 字段带时间（如 '2023-12-31 14:22:03'），它仍会被包含——这点常被忽略，尤其在日志类表里。
- 如果字段是
DATETIME或TIMESTAMP，且你只想查“2023整年”，用BETWEEN容易漏掉或误吞数据；更稳妥的是date >= '2023-01-01' AND date -
BETWEEN要求两个边界值类型一致，否则可能触发隐式转换，导致索引失效（比如一边是字符串'10'，一边是数字10） - 当 a > b 时，
BETWEEN直接返回空结果，不报错也不交换顺序——这跟直觉相反，但标准 SQL 就是这么定的
用 写区间更灵活，也更容易控制边界
手写 >= 和 组合，是实际项目中最可控的方式。特别是处理时间范围、ID 分页、数值分段统计时，开闭选择权完全在你手上。
使用场景举例：查“注册时间在 2023 年内、不含 2024 年 1 月 1 日零点之后”的用户，用 created_at >= '2023-01-01' AND created_at 比 <code>BETWEEN 更精确，也避免了时间精度带来的歧义。
- 对
TIMESTAMP字段，自动覆盖所有毫秒级时间点，不用考虑 <code>'2023-12-31 23:59:59.999'这种魔数 - 复合条件中混用
AND/OR时，显式写大小于符号逻辑更清晰，不容易因括号缺失引发优先级问题 - 某些 ORM（如 SQLAlchemy）生成的查询默认倾向用
>=+，因为它们能更好适配不同数据库对 <code>BETWEEN的实现差异
NULL 值会让 BETWEEN 和大小于行为不一致
BETWEEN 在遇到任一边界为 NULL 时，整个表达式直接返回 UNKNOWN，结果相当于 FALSE，该行不会被查出来。而显式用 >= 则可能触发三值逻辑陷阱。
常见错误现象：score BETWEEN 0 AND NULL 不报错，但永远不匹配任何行；而 score >= 0 AND score 中，后半部分恒为 <code>UNKNOWN，整条条件也为 UNKNOWN，效果一样——但后者更容易被开发者意识到问题。
- 如果业务允许
score为NULL，又想把NULL当作“未评分”单独归类，BETWEEN完全无法表达这个意图 - 涉及
COALESCE或IS NULL判断时，用大小于组合更容易嵌套，比如COALESCE(score, 0) BETWEEN 60 AND 100是合法的，但语义已偏离原始字段含义
性能上没本质区别，但写法影响索引是否生效
只要两边都是确定值、无函数包裹，BETWEEN 和等价的 >= + 在主流数据库（PostgreSQL、MySQL、SQL Server）中执行计划几乎一样，都会走范围扫描（Index Range Scan）。
真正影响性能的是写法是否“可索引”。比如 DATE(created_at) BETWEEN '2023-01-01' AND '2023-12-31' 会让索引失效，而 created_at >= '2023-01-01' AND created_at 可以。
- 别在
BETWEEN左侧写函数或表达式，如UPPER(name) BETWEEN 'A' AND 'Z'，除非你建了函数索引 - MySQL 5.7+ 对
BETWEEN有小优化：当用于主键或唯一索引时，可能提前终止扫描；但这属于引擎细节，不应依赖 - 如果字段有大量重复值（比如状态码只有 0/1/2），范围查询本身效率就不高，这时选什么语法都不如加个覆盖索引实在
边界怎么取、NULL 怎么处理、索引能不能用——这些不是语法层面的对错，而是你对数据分布和业务语义的理解是否落地到 SQL 里。写完记得看执行计划，别信“看起来差不多”。
