BETWEEN AND 更高效且语义清晰，适用于连续范围查询；而 >= AND
WHERE 条件里用 BETWEEN AND 还是 >= AND ？效果一样
语义和结果完全一致，BETWEEN AND 是 >= AND 的语法糖，MySQL、PostgreSQL、SQL Server 都如此。比如：date BETWEEN '2024-01-01' AND '2024-12-31' 等价于 date >= '2024-01-01' AND date 。
但注意：BETWEEN 是**闭区间**，包含两端值——这点常被误以为“含头不含尾”。
BETWEEN AND 在时间字段上容易出错
对 DATETIME 或 TIMESTAMP 类型，直接写 BETWEEN '2024-01-01' AND '2024-12-31' 会隐式截断为 '2024-01-01 00:00:00' 和 '2024-12-31 00:00:00'，漏掉当天其余时间。
- 正确做法是显式补全时间边界：
created_at >= '2024-01-01' AND created_at （推荐） - 或用
BETWEEN '2024-01-01 00:00:00' AND '2024-12-31 23:59:59.999'（易出错，不推荐） - PostgreSQL 支持
tsrange，MySQL 8.0+ 可配合CAST显式转类型，但不如左闭右开清晰
索引能不能走，跟写法无关，跟数据类型和边界是否可推导有关
优化器对 BETWEEN 和 >= ... AND 的处理完全一致，只要两端是确定值（非子查询、非函数调用），就能用上范围索引。
但这些情况会失效：
-
col BETWEEN DATE_SUB(NOW(), INTERVAL 7 DAY) AND NOW()—— 函数表达式，部分旧版 MySQL 可能无法精确估算范围 -
col BETWEEN @start_date AND @end_date—— 参数化变量，在预编译阶段无法确定值，可能影响执行计划稳定性 - 字段上有隐式类型转换，比如
varchar列和字符串比较时加了空格或大小写函数
可读性与团队规范比性能更重要
二者性能无差别，选哪个纯看团队习惯和上下文清晰度：
- 枚举离散值（如状态码）：
status BETWEEN 1 AND 3比status >= 1 AND status 更紧凑 - 涉及日期+时间，尤其要排除某天全部数据时，
>= AND 左闭右开更安全、无需记忆“23:59:59.999” - ORM 生成 SQL 时，有些框架（如 Django ORM）默认用
>= AND ，强行统一成BETWEEN反而增加维护成本
真正容易被忽略的是：当字段允许 NULL 且查询条件没覆盖它时，BETWEEN 和 >= AND 都不会匹配 NULL 行——这点和 IN 不同，但常在调试时被当成“数据丢了”。
