between是sql中查询闭区间的操作符，包含左右边界值；如age between 18 and 25等价于age >= 18 and age
WHERE子句里用BETWEEN查闭区间数据
直接说结论：BETWEEN是SQL里最常用也最容易写错的范围查询操作符——它查的是闭区间，即包含左右边界值。比如age BETWEEN 18 AND 25等价于age >= 18 AND age ，不是半开半闭，也不是“大于等于18且小于25”。
常见错误现象：业务方反馈“25岁用户没查出来”，结果发现前端传参把end值设成了24，或者后端拼SQL时误用了逻辑；还有人以为<code>BETWEEN能自动处理NULL，其实只要左值或右值是NULL，整条条件就返回UNKNOWN，该行直接被过滤掉。
- 左右值类型必须兼容，比如不能
date BETWEEN '2023-01-01' AND 100，MySQL会静默转成0，PostgreSQL直接报错ERROR: operator does not exist: date BETWEEN text AND integer - 字符串比较按字典序，
name BETWEEN 'Alice' AND 'Bob'会包含'Alicia'但不包含'Bobby'（因为'Bobby' > 'Bob'） - 时间字段慎用
BETWEEN配DATETIME：如果想查“2023-01-01全天”，写created_at BETWEEN '2023-01-01' AND '2023-01-01 23:59:59'容易漏掉毫秒级数据；更稳妥的是created_at >= '2023-01-01' AND created_at
PostgreSQL和MySQL对BETWEEN SYMMETRIC的支持差异
BETWEEN SYMMETRIC是PostgreSQL特有语法，允许左右值顺序颠倒仍能正确执行，比如id BETWEEN SYMMETRIC 100 AND 1等价于id BETWEEN 1 AND 100；而MySQL、SQL Server、SQLite都不支持这个关键词，写了直接报错ERROR 1064 (42000): You have an error in your SQL syntax。
使用场景：当上下界来自用户输入且无法保证大小关系时（比如前端两个可编辑日期框），PostgreSQL可用SYMMETRIC省去判断逻辑；其他数据库必须在应用层做MIN()/MAX()处理，或用CASE兜底。
- MySQL中想模拟类似行为，得手动写：
WHERE col >= LEAST(@a, @b) AND col - SQL Server没有
LEAST/GREATEST，得用IIF(@a 配合嵌套 - 所有数据库里
BETWEEN本身都不支持表达式作为边界，比如score BETWEEN avg_score - 5 AND avg_score + 5在多数引擎里非法，得先算出值再代入
和IN、>= AND 比，<code>BETWEEN有什么实际影响
语义上三者常可互换，但执行层面有差别：优化器对BETWEEN通常识别为单个范围扫描节点，而>= AND 可能被拆成两个独立条件，某些旧版本MySQL（5.6之前）甚至不会走联合索引的第二列；<code>IN则完全不适合范围，只适用于离散值列表。
性能影响明显体现在索引使用上。假设表有联合索引(status, created_at)，查WHERE status = 'active' AND created_at BETWEEN '2023-01-01' AND '2023-01-31'能高效利用索引；但若写成created_at >= '2023-01-01' AND created_at ，部分MySQL版本可能只用到<code>status单列，created_at变成filter而非index condition。
- Oracle中
BETWEEN会被重写为>= AND ，无区别；但在执行计划里仍显示为<code>BETWEEN，方便DBA识别意图 - SQLite对
BETWEEN做了特殊优化，比手写>= AND 略快（微秒级），但仅限于简单数值比较 - 所有数据库中，
BETWEEN都不能用于全文索引或空间索引的范围查询，比如geom_column BETWEEN ...无效，必须用ST_Within等专用函数
容易被忽略的时区与字符集陷阱
BETWEEN本身不处理时区转换，也不感知字符集排序规则。这意味着：如果你的created_at是TIMESTAMP WITH TIME ZONE类型（如PostgreSQL），而客户端连接时区是UTC+8，那么BETWEEN '2023-01-01' AND '2023-01-01'实际查的是UTC时间的2022-12-31 16:00:00到2023-01-01 16:00:00——表面看是同一天，实则跨了24小时。
字符集问题更隐蔽：MySQL默认utf8mb4_0900_as_cs排序规则下，name BETWEEN 'a' AND 'z'会包含带重音符号的á、ñ（因为它们在Unicode序中落在a-z之间）；但换成utf8mb4_bin就严格按字节比，á（0xC3 0xA1）远大于z（0x7A），直接被排除。
- 时间字段统一用
UTC存储，查询时用AT TIME ZONE转换后再BETWEEN，别依赖连接时区 - 字符串范围查询前确认排序规则：
SHOW FULL COLUMNS FROM table_name LIKE 'col_name';看Collation列 - 任何涉及中文、emoji或大小写混合的
BETWEEN都建议改用LIKE或正则，避免排序规则引发意外匹配
事情说清了就结束
