BETWEEN 在 SELECT 中为闭区间查询，包含左右边界值，等价于 col >= low AND col = 与

SELECT 中 BETWEEN 的基本写法和边界行为

BETWEEN 在 SELECT 里是闭区间查询，包含左右边界值，等价于 col >= low AND col ，不是半开区间。这点容易被误读，尤其当字段含小数、时间戳或字符串时，边界值是否命中直接影响结果。

• 写法固定：WHERE column_name BETWEEN value1 AND value2，value1 必须 ≤ value2，否则返回空结果（MySQL/PostgreSQL/SQL Server 均如此）
• 字符串比较按字典序，'apple' BETWEEN 'a' AND 'b' 成立，但 'banana' BETWEEN 'a' AND 'b' 不成立（因为 'banana' > 'b'）
• 日期时间类型要注意时区和精度，created_at BETWEEN '2024-01-01' AND '2024-01-31' 会包含 '2024-01-31 00:00:00'，但不包含 '2024-01-31 12:00:00'（因隐式转换为 '2024-01-31 00:00:00'）

用 BETWEEN 查时间范围时的常见陷阱

时间字段查“某天全天”最容易出错：直接写 BETWEEN '2024-01-01' AND '2024-01-01' 只匹配精确到秒的 '2024-01-01 00:00:00'，几乎查不到数据。

• 正确做法是组合使用：用 BETWEEN '2024-01-01 00:00:00' AND '2024-01-01 23:59:59'（仅限秒级精度）
• 更健壮的写法是避开 BETWEEN，改用 created_at >= '2024-01-01' AND created_at ，避免时间精度丢失和夏令时问题
• PostgreSQL 支持 TIMESTAMP 字面量带时区，如 '2024-01-01'::timestamptz，但 BETWEEN 两侧必须同类型，混用 DATE 和 TIMESTAMP 可能触发隐式转换导致索引失效

BETWEEN 与索引效率的关系

BETWEEN 本身不阻碍索引使用，但能否走索引取决于字段类型、表达式是否可 SARGable（可搜索参数化），以及数据库优化器判断。

• 对已建索引的列直接查，如 WHERE status BETWEEN 1 AND 3，通常能用上索引
• 但写成 WHERE CAST(id AS VARCHAR) BETWEEN '100' AND '200' 就无法走 id 索引——函数包裹字段是常见索引失效原因
• 复合索引中，BETWEEN 字段必须位于索引前导列之后的连续位置才可能生效；例如索引是 (a, b, c)，则 WHERE a = 1 AND b BETWEEN 2 AND 5 可用索引，但 WHERE b BETWEEN 2 AND 5 就不行

替代 BETWEEN 的等效写法及适用场景

有些场景 BETWEEN 不够灵活，比如要查“不在某个范围”，或需要动态端点，这时手写逻辑更可控。

• NOT BETWEEN 是合法语法，但语义易混淆，建议拆成 NOT (col >= a AND col 或直接写 <code>col b
• 数值分段统计时，用 CASE WHEN col BETWEEN 0 AND 10 THEN 'low'... 没问题；但若分段边界来自另一张表，就得用 JOIN + 范围条件，此时 BETWEEN 无法参数化，得换 col >= low AND col
• 某些方言（如 SQLite）不支持 BETWEEN 用于 INSERT ... SELECT 的子查询字段别名，必须显式写出范围条件

边界值含义、时间精度处理、索引可用性这三点，实际写 SQL 时漏掉任何一个都可能让查询结果不对或慢得离谱。