BETWEEN是SQL中闭区间操作符，包含左右边界值，等价于>= AND <=；要求左边界≤右边界，否则返回空结果；适用于数值、日期、字符串类型，但需注意类型兼容性、NULL处理及时间精度问题。
SQL BETWEEN 查询的边界行为必须明确
BETWEEN 是闭区间操作符，包含左右两端值。很多人误以为它等价于 >= AND 的简写，但实际语义完全一致——<code>BETWEEN 1 AND 5 就是 value >= 1 AND value ，不是半开区间。
常见错误是把 BETWEEN 当成“中间值”筛选，比如写 WHERE age BETWEEN 20 AND 30 却期望排除 20 和 30，结果查出意外数据。
- 如果字段是
DATE类型，注意时分秒：created_at BETWEEN '2024-01-01' AND '2024-01-31'实际等价于'2024-01-01 00:00:00' ，会漏掉 1 月 31 日全天其他时间的数据 - 字符串比较依赖排序规则（collation），
name BETWEEN 'A' AND 'M'可能不包含大小写混合结果，具体取决于数据库默认设置 - NULL 值永远不满足
BETWEEN条件，哪怕左/右边界是 NULL ——col BETWEEN NULL AND 10返回空结果
日期范围查询必须手动补全时间精度
用 BETWEEN 查日期最容易踩坑的地方，就是没意识到它对时间部分的截断逻辑。直接写 '2024-01-01' AND '2024-01-31' 在多数数据库中会被隐式转为 '2024-01-01 00:00:00' 和 '2024-01-31 00:00:00'，导致 31 日下午的数据丢失。
- 安全做法是显式指定时间边界：
created_at BETWEEN '2024-01-01 00:00:00' AND '2024-01-31 23:59:59' - 更推荐用开区间替代：
created_at >= '2024-01-01' AND created_at ，避免秒级精度问题，也利于索引使用 - PostgreSQL 支持
DATE类型直接比较，可写created_at::DATE BETWEEN '2024-01-01' AND '2024-01-31'，但会强制类型转换，可能影响索引命中
数值型字段用 BETWEEN 要小心数据类型隐式转换
当字段是 DECIMAL 或 FLOAT，而 BETWEEN 右侧用整数时，某些数据库（如 MySQL）会做隐式转换，但精度可能出问题。例如 price BETWEEN 9.99 AND 19.99 看似合理，但如果 price 是 FLOAT，二进制浮点误差可能导致 19.99 实际存为 19.989999...，被排除在外。
- 浮点字段慎用
BETWEEN，优先改用>=和配合小数位数校验 - 整数字段没问题，但要注意符号：负数范围如
score BETWEEN -5 AND 5正确，但写成BETWEEN 5 AND -5会返回空（BETWEEN 要求左值 ≤ 右值） - 字段含大量 NULL 时，
BETWEEN不会匹配它们，如需包含，得额外加OR col IS NULL
性能提示：BETWEEN 能走索引，但有前提
BETWEEN 本身不阻碍索引使用，但它是否生效，取决于字段是否在索引最左前缀、以及是否有函数包裹。比如 UPPER(name) BETWEEN 'A' AND 'Z' 就无法利用 name 字段上的普通索引。
- 复合索引中，只有连续的最左前缀列参与范围扫描：
INDEX(a,b,c)，WHERE a=1 AND b BETWEEN 2 AND 4可用索引；但WHERE a=1 AND c BETWEEN 3 AND 5只能用到 a，b 和 c 部分失效 - MySQL 8.0+ 对
BETWEEN有优化，但 SQL Server 和 Oracle 仍建议用>= AND 写法，避免解析歧义 - 如果 WHERE 中混用
OR和BETWEEN，执行计划容易退化，应拆成 UNION 或重写条件
