BETWEEN AND是闭区间操作符，包含左右边界值，等价于>= AND <=，而非> AND <；常见错误是误认为其等价于> AND <或>= AND <。
WHERE子句里用BETWEEN AND写法最简但易错
BETWEEN AND是闭区间操作符，包含左右边界值。很多人误以为它等价于>= AND 就完全安全，其实不然——当字段含<code>NULL、或类型隐式转换发生时，行为可能出人意料。
正确写法示例：
SELECT * FROM orders WHERE amount BETWEEN 100 AND 500;这等价于
amount >= 100 AND amount ，但数据库会一次性做范围判断，某些引擎（如PostgreSQL）在有索引时能更好利用B-Tree结构。
- 必须确保左右值类型一致：若
amount是DECIMAL，不要写BETWEEN '100' AND '500'，字符串比较会导致全表扫描甚至错误排序 -
BETWEEN不支持列名颠倒：写成BETWEEN 500 AND 100不会自动交换，结果恒为FALSE - 对日期字段要小心时分秒：若
created_at是TIMESTAMP，BETWEEN '2024-01-01' AND '2024-01-31'实际查的是2024-01-01 00:00:00到2024-01-31 00:00:00，丢掉最后一天的全部数据
日期范围过滤必须显式补全时间部分
用BETWEEN查日期最容易漏掉当天下午的数据。比如想查2024年1月整月，直接写BETWEEN '2024-01-01' AND '2024-01-31'，MySQL或PostgreSQL会把右值解释为'2024-01-31 00:00:00'，所有'2024-01-31 10:23:45'都被排除。
- 安全做法是用开区间+
： <code>created_at >= '2024-01-01' AND created_at - 如果坚持用
BETWEEN，右值必须带时间：BETWEEN '2024-01-01' AND '2024-01-31 23:59:59.999'（注意SQL Server毫秒精度是.997） - PostgreSQL可用
DATE类型字段配合::DATE转换，但会失去年月日以外信息，且无法走索引
NULL值会让BETWEEN整个条件失效
只要被比较的字段值为NULL，column BETWEEN a AND b永远返回UNKNOWN，而WHERE只认TRUE，所以该行一定被过滤掉——哪怕你本意是“允许空值也通过”。
- 若需包含
NULL，必须显式加判断：(amount BETWEEN 100 AND 500) OR amount IS NULL - 不能写成
amount BETWEEN 100 AND 500 OR NULL——语法错误，OR后面必须是布尔表达式 - 有些ORM生成的SQL会悄悄把
NULL转成IS NULL，但原生SQL中BETWEEN和NULL就是绝缘的
性能上BETWEEN并不总比拆开快
多数情况下BETWEEN和手写>= AND 执行计划一致，但某些场景下差异明显：
- SQL Server对
BETWEEN有时会启用更激进的并行计划，而手写两个条件可能走串行；反过来，Oracle 12c+对拆开写法更容易应用函数索引 - 如果左值或右值是子查询或函数调用（如
BETWEEN (SELECT min_val FROM cfg) AND (SELECT max_val FROM cfg)），每次比较都可能重复执行子查询，不如先用WITH绑定变量 - 对非数字类型（如字符串），
BETWEEN 'a' AND 'm'依赖字符集排序规则，中文环境下可能不符合字典序直觉，建议用COLLATE明确指定
边界值的语义准确性，比语法是否简洁重要得多。写完记得用EXPLAIN看执行计划，尤其当数据量上百万后，一个没意识到的隐式类型转换就能让索引彻底失效。
