如何从SQL中获取指定范围数据：BETWEEN操作符的应用

陆砚码

2026-11-05 • 👁 0人浏览过

BETWEEN是SQL中查询闭区间的操作符，包含左右边界值；如age BETWEEN 18 AND 25等价于age >= 18 AND age <= 25。 WHERE子句里用

BETWEEN

查闭区间数据直接说结论：

BETWEEN

是SQL里最常用也最容易写错的范围查询操作符——它查的是闭区间，即包含左右边界值。比如

age BETWEEN 18 AND 25

等价于

age >= 18 AND age ，不是半开半闭，也不是“大于等于18且小于25”。

常见错误现象：业务方反馈“25岁用户没查出来”，结果发现前端传参把

end

值设成了24，或者后端拼SQL时误用了

<

逻辑；还有人以为

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 < '2023-01-02'

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 <= GREATEST(@a, @b)

SQL Server没有

LEAST

GREATEST

，得用

IIF(@a < @b, @a, @b)

配合嵌套所有数据库里

BETWEEN

本身都不支持表达式作为边界，比如

score BETWEEN avg_score - 5 AND avg_score + 5

在多数引擎里非法，得先算出值再代入和

IN

、

>= AND <=

比，

BETWEEN

有什么实际影响语义上三者常可互换，但执行层面有差别：优化器对

BETWEEN

通常识别为单个范围扫描节点，而

>= AND <=

可能被拆成两个独立条件，某些旧版本MySQL（5.6之前）甚至不会走联合索引的第二列；

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 <= '2023-01-31'

，部分MySQL版本可能只用到

status

单列，

created_at

变成filter而非index condition。 Oracle中

BETWEEN

会被重写为

>= AND <=

，无区别；但在执行计划里仍显示为

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

或正则，避免排序规则引发意外匹配事情说清了就结束

相关文章