MySQL BETWEEN AND 是闭区间查询，等价于 >= AND
MySQL BETWEEN AND 本质就是闭区间查询
它不是“模糊匹配”，而是严格等价于 >= 取值1 AND ，边界值一定包含在内。比如 <code>age BETWEEN 24 AND 25 会查出 age = 24 和 age = 25 的所有记录，这点和直觉一致，但容易被误以为“中间值才有效”。
- 数值类型（
INT、DECIMAL）用起来最安全，语义清晰 - 字符串类型也能用，但依赖字符集排序规则（如
name BETWEEN 'A' AND 'M'），实际效果可能因 collation 而异，不推荐用于业务关键字段 -
NOT BETWEEN是完整否定，等价于取值2，不是“排除中间”那么简单
datetime 字段用 BETWEEN 必须手动补全时分秒
这是线上最容易翻车的点：对 DATETIME 或 TIMESTAMP 字段直接写 BETWEEN '2024-10-29' AND '2024-10-30'，MySQL 会自动补成 '2024-10-29 00:00:00' 到 '2024-10-30 00:00:00'，结果漏掉 10 月 30 日全天的数据。
- 正确做法是显式写出右边界上限：
BETWEEN '2024-10-29 00:00:00' AND '2024-10-30 23:59:59' - 更健壮的写法是用左闭右开：
create_time >= '2024-10-29' AND create_time ，避免秒级精度问题，也利于索引使用 - 如果字段是
DATE类型（无时间部分），则BETWEEN '2024-10-29' AND '2024-10-30'是安全的，等价于当天整日
BETWEEN 和手写 >= AND 性能没区别，但可读性更强
优化器会把两者重写为完全相同的执行计划，只要字段有索引，范围扫描就能生效。但可读性差异明显——尤其当条件嵌套或带函数时。
- 推荐用
BETWEEN表达明确的连续区间，比如价格、年龄、ID 段、状态码范围 - 避免在
BETWEEN左侧加函数或表达式，例如YEAR(create_time) BETWEEN 2024 AND 2025会导致索引失效 - 如果范围逻辑复杂（比如动态偏移、多字段组合），不如拆成显式比较，别硬套
BETWEEN
注意取值顺序：BETWEEN A AND B 要求 A ≤ B
MySQL 不会自动交换大小，如果写成 price BETWEEN 200 AND 100，结果永远为空——它不会报错，也不会警告，静默返回空集。
- 开发阶段建议加 SQL 检查逻辑，或用 Lint 工具拦截反向
BETWEEN - 参数化查询时，务必确保传入的起始值不大于终止值，尤其从用户输入或配置中读取时
- 日期场景下常见错误：把开始时间当成结束时间传入，比如
BETWEEN ? AND ?却把end_date放前面
真正麻烦的从来不是语法本身，而是 datetime 类型的时间截断行为和边界隐式补零——这两点在线上查不到数据时，最容易让人反复怀疑是不是索引坏了、是不是数据丢了。
