鄂奎阿先讲一个我实际遇到过的排错现场。运营同事要拉某个站点整个三月的订单明细，SQL写得非常简单，条件就是 create_time BETWEEN '2023-03-01' AND '2023-03-31'。语法挑不出任何毛病，可结果一出来，所有人都愣住：3月31日当天只有零点零几分的数据，再往后一条都没有。后来查了很久才发现，问题不在表，也不在数据，而是出在这个看起来最基础的 BETWEEN 上。这类问题在团队里不是第一次出现，以后也不会是最后一次。SQL 基础中的 BETWEEN 常用用法，一句话就能说完，但它背后的边界条件、数据类型细节、NULL 处理逻辑和索引使用方式，足以让新手甚至部分老手踩上几轮坑。这篇文章我不打算只罗列语法示例，我想把实际业务里最容易出问题的几个场景拆开讲清楚，适合正在学 SQL 的同学、经常写报表的数据分析师，以及后端接口里经常拼查询条件的开发一起看看。
1. 边界问题比你想的复杂：先确认 BETWEEN 到底是双闭还是单闭
1.1 一个少了 3 月 31 日数据的真实案例
上面那个订单查询的场景，最终定位到的原因让我印象很深。create_time 字段的类型是 DATETIME，不是单纯的 DATE。当你在 SQL 里写 BETWEEN '2023-03-01' AND '2023-03-31' 时，数据库会先对两边的字符串常量做类型转换。'2023-03-31' 被转换成时间戳以后，实际值是 2023-03-31 00:00:00，而不是很多人潜意识里以为的 2023-03-31 23:59:59。
于是整条 SQL 的真实语义变成：查询 create_time >= '2023-03-01 00:00:00' 且 create_time <= '2023-03-31 00:00:00' 的记录。这等于把 3月31日零点之后的所有订单都排除在外。那为什么结果里还留着 31 日零点零几分的数据？因为零星几条的时间可能刚好是 2023-03-31 00:00:00 整点，或者非常接近。这个事故其实不是 BETWEEN 的语法问题，而是“日期字符串在 DATETIME 比较下默认补零”这个隐含规则没有引起足够的重视。
如果你也遇到类似情况，最直接的排查方法，就是把你写的 BETWEEN 临时改写成显式的 >= 和 <=，然后分别看两个边界值在数据库里转换以后到底长什么样。拿 MySQL 举例，可以直接执行一句 SELECT CAST('2023-03-31' AS DATETIME);，看到返回结果是 2023-03-31 00:00:00，问题就马上清楚了。PostgreSQL 里则可以用 SELECT '2023-03-31'::TIMESTAMP; 来验证。不同数据库的转换行为大同小异，核心思路是一样的：先确认边界到底落在哪一秒，再去看数据。
1.2 BETWEEN 的等价写法与双闭区间本质
BETWEEN ... AND ... 的本质是一个双闭区间，也就是两端都包含。很多刚接触 SQL 的同学会误以为它是“大于等于左边，小于右边”，或者“在两者之间但不包含边界”，这种理解在做数字筛选时最容易暴露。
比如要查年龄在 18 到 35 岁之间的用户，WHERE age BETWEEN 18 AND 35 会包含 18 岁和 35 岁这两个端点。它的标准等价写法是：
sql复制WHERE age >= 18 AND age <= 35
这两条 SQL 在执行结果上是一致的，但正因为这个语法太过简短，很多人反而没有认真去推理它的等价关系。尤其是当边界本身是字符串或日期时，真正的边界值会被隐式转换、时间补零、排序规则等因素二次加工，最终查出来的数据和你脑补的区间可能完全不一样。
我个人的习惯是：任何 BETWEEN 条件在写进重要查询之前，先在心里或者草稿纸上把它转成 >= 和 <=，再逐一看边界值的类型。对于日期时间字段，把右边界写成 '2023-03-31 23:59:59' 这类值并不推荐，因为不同数据库对小数秒的精度处理不一致，MySQL 的 DATETIME 可以带 6 位小数秒，PostgreSQL 的 TIMESTAMP 精度更灵活，SQL Server 的 DATETIME2 精度也不同，硬凑“一天的最后一刻”往往会在凌晨数据上出问题。后面我会详细说更稳妥的写法。
1.3 数字区间没有争议，争议往往出在数据类型上
如果列本身是整数或小数，BETWEEN 的双闭区间语义没有任何歧义。比如统计某个价格区间内的商品数量，WHERE price BETWEEN 100 AND 200 包含 100 元和 200 元整，不会有人说这是错的。
真正容易出问题的是“类型看起来不像数字的数字”。这句话怎么理解？比如有一个字段在表里是 VARCHAR，里面存的却全是数字字符串。当你写 WHERE score BETWEEN 60 AND 100 时，数据库为了比较 VARCHAR 和整数，很可能对字段做隐式转换，把每一行都转换成数值再比较。这种情况下，如果字段值里有非数字内容，可能会转换失败，或者因为无法走索引导致查询特别慢。
还有一种更隐蔽的情况，是字段存的是字符串形式的日期。比如有一列 order_date_str 类型是 VARCHAR(10)，里面按 'YYYY-MM-DD' 格式存日期。你写 WHERE order_date_str BETWEEN '2023-01-01' AND '2023-01-31'，表面看没问题，其实它是在做字符串字典序比较。只要格式统一、位数一致，这种比较能歪打正着得到正确结果；但一旦某天有脏数据写成了 '2023-1-01' 或者 '2023-01-1'，字典序就完全乱了。所以看到 BETWEEN 的条件列，第一步要确认真实类型，不要相信“看起来像日期/数字”就一定是日期/数字。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 日期与字符串场景最容易踩坑：不要把“看起来能查”当成“查得对”
2.1 日期加时间后，右边界默认是当天的 00:00:00
日期时间字段是 BETWEEN 应用中最容易翻车的领域，而且翻车的方式非常有规律。当你写的右边界只有一个日期字符串，比如 '2023-05-31'，数据库在比较 DATETIME/TIMESTAMP 时会自动把它当成 '2023-05-31 00:00:00'。这意味着当天 00:00:00 之后的所有时间都不会被包含。
我见过不少老系统里的 SQL，会把右边界写成 BETWEEN '2023-05-01' AND '2023-05-31 23:59:59'。这种写法在 MySQL 旧版本里通常能查到大多数数据，但它依赖一个重要假设：表中不会存在 2023-05-31 23:59:59.500 这种小数秒数据。一旦时间精度扩展到毫秒、微秒，这个边界就会漏掉一批记录。如果表中未来可能有更细的时间粒度，或者代码要适配不同数据库，这种“凑 23:59:59”的方案就会变成定时炸弹。
那正确做法是什么？我强烈建议，查询某个连续时间段时，使用“含头不含尾”的区间，也就是左闭右开：
sql复制WHERE create_time >= '2023-05-01'
AND create_time < '2023-06-01'
这条 SQL 的语义是“从 5 月 1 日零点开始，到 6 月 1 日零点之前”，正好完整覆盖整个 5 月。它不需要关心一天里最后一秒到底是多少，也不会漏掉任何带小数秒的数据。这个写法虽然比 BETWEEN 长了几个字符，但逻辑可靠性提高了不少。尤其当字段是 TIMESTAMP 且有时区换算、夏令时调整等复杂情况时，这种“下界闭、上界开”的区间能减少非常多隐性 Bug。
有的同学可能会问，那 BETWEEN 是不是在日期时间字段上就该完全不用？也不是。如果列的类型就是 DATE，不包含时间部分，那么 BETWEEN '2023-05-01' AND '2023-05-31' 是安全且直观的。因为 DATE 类型没有“当天零点以后”的概念，边界就是边界。麻烦永远出在 DATETIME、TIMESTAMP 这类带时间部分的类型上。我的经验是第一，写条件前先看字段类型；第二，凡是时间字段一律优先使用 >= 和 < 组合，而不是 BETWEEN。
2.2 字符串边界不是“英文字母区间”
有大量新手会把 BETWEEN 用在字符串上，最常见的一个错误想法是：查所有以 a 到 z 开头的姓名，写 WHERE name BETWEEN 'a' AND 'z'。这个想法听着合理，实际上问题很大。字符串比较在 SQL 里不是按“我指定的第一个字符”去截断，而是按完整的字典序逐字符比较。
举一个实际例子，如果表里有一个人的名字是 "Zhang"，它是否满足 BETWEEN 'a' AND 'z'？按字典序，先比较首字符，"Z" 或者 "z"。在大小写不敏感的排序规则下，它确实落在 a 到 z 之间；在有些大小写敏感的排序规则里，大写的 "Z" 的二进制值大于小写 "z"，可能就不在范围内。这还只是大小的差异。更常见的坑是，BETWEEN 'a' AND 'z' 会包含所有首字母为 a 到 z 的完整字符串，你想筛选的“首字母在 a 到 z 之间”其实会被扩展成“以 a 到 z 开头的任意字符串”，结果大量以 z 开头的名字也会被包含进来，因为 'Zhang' 确实大于等于 'a' 且小于等于 'z'。
如果真想按前缀筛，建议明确使用 LIKE 或者左闭右开：
sql复制WHERE name >= 'a' AND name < 'z'
这条 SQL 的含义是“所有以 a 开头，以及以 a 到 y 之间任意字符开头，但不包含 z 开头的记录”。这里也需要看数据库的排序规则。如果需求是查以 A 到 Z 开头的记录，最不容易出错的是 WHERE UPPER(name) LIKE 'A%' OR UPPER(name) LIKE 'B%' ...，或者直接 WHERE name REGEXP '^[A-Z]'。每个数据库正则函数的写法略有差异，但思路是一样的：不要盲目用 BETWEEN 处理“字符区间”这种需求。
2.3 日期字符串与排序规则的连带问题
存日期时用什么类型，决定了能不能用 BETWEEN。如果列是真正的 DATE 类型，直接用 BETWEEN 没问题。如果列是字符串，即使格式像日期，也建议先转换字段类型，或者接受“按字典序比较”的事实：只要格式固定且都是等宽的 YYYY-MM-DD，字典序恰好和时间顺序一致，所以能用；一旦格式不统一，'2023-1-1' 这种值会比较得很诡异，因为按字典序它排在 '2023-01-01' 前面还是后面，完全取决于字符编码和长度。
从工程实践上看，既然数据库提供日期类型，推荐在表设计阶段就把日期字段定义成 DATE、DATETIME 或 TIMESTAMP，不要让字符串承担日期语义。很多报表 SQL 慢，不是查得不对，而是历史表设计时图省事，把日期存成 VARCHAR，后续所有查询都只能做全表扫描，甚至 BETWEEN 的结果偶尔正确偶尔错误。如果遇到这种表，我通常用统一的转换函数先转成日期再比较，虽然转换过程会让索引失效，但至少保证了正确性。正确性永远排在性能前面。
3. NOT BETWEEN 和三值逻辑：NULL 数据为什么会悄悄消失
3.1 当列里有 NULL，BETWEEN 和 NOT BETWEEN 都不会命中
SQL 里的逻辑判断和程序语言的布尔逻辑不太一样，它有三种结果：TRUE、FALSE 和 UNKNOWN。NULL 参与任何比较运算，结果基本都是 UNKNOWN，而 WHERE 子句只会保留结果为 TRUE 的行。
这意味着，如果一张员工表里有些人的 salary 是 NULL，那么：
sql复制WHERE salary BETWEEN 3000 AND 8000
不会返回这些 NULL 薪资的员工，这符合预期。问题出在很多人写“排除”条件时，以为 NOT BETWEEN 会把 NULL 员工也返回出来：
sql复制WHERE salary NOT BETWEEN 3000 AND 8000
这条 SQL 的实际结果同样不会包含 NULL 薪资的员工。原因很简单：salary = NULL 时，salary BETWEEN 3000 AND 8000 的结果是 UNKNOWN，NOT UNKNOWN 还是 UNKNOWN，WHERE 仍然不保留它。很多人在做“剔除某个区间”的查询时，发现结果里的行数比预想少了很多，就是因为 NULL 行被三层逻辑“静默过滤”掉了。
处理办法也简单：如果你希望 NULL 也出现在结果里，必须单独补一个条件：
sql复制WHERE salary NOT BETWEEN 3000 AND 8000
OR salary IS NULL
这里要注意括号。如果整个查询还有其他 AND 条件，直接加 OR salary IS NULL 可能会打破原来的逻辑，所以最好把整个区间排除条件用括号包起来，比如：
sql复制WHERE (salary NOT BETWEEN 3000 AND 8000 OR salary IS NULL)
AND department = '研发部'
3.2 NOT BETWEEN 的等价改写与“排除”语义错误
拿数字区间举例，NOT BETWEEN 的标准等价写法不是简单加个 !，而是：
sql复制WHERE salary < 3000 OR salary > 8000
注意这里用的是 OR，不是 AND。很多人会下意识写成 salary < 3000 AND salary > 8000，这样的条件在任何值上都为假，永远查不到数据。这个错误在各种报表 SQL 里太常见了。排错的时候，把 NOT BETWEEN 改写成 < 和 > 的 OR 组合，可以更清楚地看到边界和 NULL 的处理方式。
如果业务需求是“把所有不在某个折扣区间的商品筛选出来做人工确认”，我建议写成下面这种更显式的逻辑，方便后续维护：
sql复制WHERE price < 100
OR price > 500
OR price IS NULL
这比 NOT BETWEEN 100 AND 500 多了三行，但每个读到这段 SQL 的人都能一眼明白：低价的要处理、高价的要处理、没定价的也要处理。当 SQL 要表达“人为排除 + 空值兜底”的复杂业务语义时，宁可写长一点，也不要秀技巧。
3.3 多层条件叠加时，AND/OR 的优先级会让结果悄悄扩大
SQL 里 AND 的优先级高于 OR。这一点在 BETWEEN 组合使用时非常容易被忽略。比如：
sql复制WHERE department = '研发部'
AND salary BETWEEN 10000 AND 20000
OR level = 'P6'
这条 SQL 的真实执行逻辑是：
sql复制WHERE (department = '研发部' AND salary BETWEEN 10000 AND 20000)
OR level = 'P6'
也就是说，所有 P6 员工都会被查出来，哪怕他们不在研发部，也不在薪资区间内。这往往不是写 SQL 的人想要的结果。想要的是“研发部里薪资在 1 万到 2 万之间的人，或者研发部里 P6 的人”，那就必须加括号：
sql复制WHERE department = '研发部'
AND (salary BETWEEN 10000 AND 20000 OR level = 'P6')
我处理过不少因 OR 优先级问题导致的“数据突然变多”案例。建议不要在一条 SQL 里堆太多 AND 和 OR 混合条件。如果业务筛选逻辑确实复杂，宁可拆成多条 SQL，或者在代码层做组合，也不要让一条 SQL 变成没人敢维护的逻辑迷宫。
4. BETWEEN 的隐藏价值：区间 JOIN、分桶统计与离散查询的选择
4.1 BETWEEN 做区间 JOIN：会员等级、分数档位这类需求
很多人提到 BETWEEN，第一反应是 WHERE 条件。但在实际项目里，它还有一个很有用的场景：在两个表之间做非等值关联。比如有一张学生分数表，一张成绩等级表，等级表里存的不是每个学生对应的等级，而是分数范围，例如 A 对应 90 到 100，B 对应 80 到 89。这时就可以用 BETWEEN 把两张表关联起来：
sql复制SELECT s.student_name,
s.score,
g.grade
FROM student_score s
JOIN score_level g
ON s.score BETWEEN g.min_score AND g.max_score
这种写法比在应用层写一层循环判断要高效得多，尤其是数据量大时，一条 SQL 就能完成区间匹配。
使用区间 JOIN 时要特别留意“区间是否重叠”。如果两张表的区间条件有重叠，一个学生可能会同时匹配多条等级记录，导致结果翻倍。比如等级表里 A 档是 90 到 100，B 档是 85 到 95，那么 92 分会同时匹配 A 和 B，查询结果就会重复。为避免这种问题，设计等级表时就应该保证区间互不重叠。上线前可以用一条查询快速检查：
sql复制SELECT a.level_name, b.level_name
FROM score_level a
JOIN score_level b
ON a.min_score <= b.max_score
AND a.max_score >= b.min_score
AND a.level_name <> b.level_name
如果这个查询有结果，说明等级区间存在重叠，需要先修数据再跑业务。
同样的思路还适用于会员等级匹配、绩效档位计算、快递费用区间计算等场景。核心价值就是：把“某个数值落在哪个区间”的查询从代码搬到数据库里，让 SQL 直接完成这件事。
4.2 CASE WHEN 分桶时，边界重叠会重复计数
用 CASE WHEN 配合 BETWEEN 做连续数值分桶统计，也是常见需求。例如把用户按消费金额分成几个档位，然后统计各档位人数：
sql复制SELECT
CASE
WHEN amount BETWEEN 0 AND 100 THEN '低消费'
WHEN amount BETWEEN 100 AND 500 THEN '中消费'
WHEN amount BETWEEN 500 AND 1000 THEN '高消费'
ELSE '超高消费'
END AS amount_bucket,
COUNT(*)
FROM orders
GROUP BY amount_bucket;
这段 SQL 看起来没问题，但实际分桶时，消费 100 元的用户会被算进“低消费”，消费 500 元的用户会被算进“中消费”，因为每个区间都是双闭的，端点被重复占用。很多统计口径不一致的问题就是这样产生的。
在做分桶统计时，我更推荐“左闭右开”的写法，让每个档位的下界包含、上界不包含：
sql复制CASE
WHEN amount >= 0 AND amount < 100 THEN '低消费'
WHEN amount >= 100 AND amount < 500 THEN '中消费'
WHEN amount >= 500 AND amount < 1000 THEN '高消费'
ELSE '超高消费'
END
这样每个金额值只会落到一个桶里，不会重复。BETWEEN 本身不是不能用，而是当你用离散的“0-100、100-500、500-1000”这种相邻区间做分桶时，双闭区间天然会产生边界重叠。反过来，如果分桶的边界本身是现实中离散的点，比如 0、100、500 分别代表某一档，那写 BETWEEN 也无可厚非，关键是把口径先约定好。
4.3 离散值查询别用 BETWEEN
还有一类反模式，就是把 BETWEEN 用在枚举值或 ID 列表上。比如想查订单状态为 1、2、3 的三类订单，看到数字连续，就写成：
sql复制WHERE order_status BETWEEN 1 AND 3
这跟 IN (1,2,3) 在结果上一样，但表达语义却非常危险。原因有二：第一，如果后需求改成查状态 1、3、5，BETWEEN 1 AND 5 会把状态 2、4 也带进来，数据量一旦变大就很难发现；第二，如果这些数字对应有含义的枚举，阅读代码的人很难从 BETWEEN 1 AND 3 看出它到底想表达什么状态组合。业务含义越明确的枚举，越应该用 IN 列表：
sql复制WHERE order_status IN (1, 2, 3)
BETWEEN 最擅长的是表达“连续的数值区间”，而离散集合应该交给 IN 来处理。这不是对错问题，而是代码可读性和未来演进的问题。写 SQL 不是给自己看的，是要让三个月后的自己看到条件就知道当时意图。
5. 隐式转换与索引失效：BETWEEN 慢查询的真正原因
5.1 类型不匹配引发隐式转换：索引没坏，是没用上
在表数据量小的时候，BETWEEN 的性能问题基本感觉不到。一旦表达到几百万甚至上千万行，慢查询就出现了。最常见的慢查询原因，不是 BETWEEN 本身，而是字段类型和比较值类型不一致导致的隐式转换。
举个例子，商品表里促销价字段 promo_price 是 DECIMAL，你在 Java 代码里拼 SQL 时，如果不小心把价格参数包装成字符串拼进去：
sql复制WHERE promo_price BETWEEN '10.00' AND '99.99'
数据库可能要把字段值或者字符串值转换成同一种类型再比较。如果优化器决定对列做转换，那么这个列上的索引基本就失效了。虽然结果可能正确，但执行计划会变成全表扫描。你用 EXPLAIN 查看时会发现 type 是 ALL，而正常范围查询应该是 range。
定位这类问题的方法很简单：用 EXPLAIN 看执行计划，重点看 type 和 key 列。type = range 且用到索引时，说明查询比较健康；type = ALL 说明是全表扫描。此时第一个怀疑点就是类型不匹配。注意，写 SQL 的时候，参数类型要跟字段类型保持一致，字符串列就传字符串，日期列就传日期，数值列就传数值。
5.2 函数包裹列，BETWEEN 也会失去范围扫描能力
另一种让索引失效的典型场景，是对字段本身做函数运算。很多新手在筛选日期时喜欢写成：
sql复制WHERE DATE(create_time) BETWEEN '2023-05-01' AND '2023-05-31'
原因是这样看起来直观，把时间字段转成日期再去比较。但问题在于，DATE(create_time) 是对每一行先执行一次函数，然后拿函数结果和常量比较。数据库索引存的是原始 create_time 的值，函数处理后的结果和原始值之间没有顺序关系，所以无法直接走索引范围扫描，只能全表扫。
更好的写法是直接对原始字段做范围条件：
sql复制WHERE create_time >= '2023-05-01'
AND create_time < '2023-06-01'
两边写法返回的数据基本一样，但性能差别可能是几个数量级。在慢 SQL 优化中，这种问题非常常见。使用 BETWEEN 时也一样，左边界和右边界可以随便包函数，但条件左边的字段尽量不要套函数，如果实在需要对字段做转换后再比较，建议考虑生成列或冗余字段。
5.3 从写法习惯上给查询留一条“快路径”，并顺手防注入
除了类型匹配和函数包裹，还有一点容易被忽略：条件里的常量值也要避免歧义。比如某些数据库里，字符串和日期常量之间的转换规则和时区设置有关。如果参数传到 SQL 里是一个带时区信息的字符串，而字段存的是 UTC 时间，那么 BETWEEN 的边界就会整体偏移，虽然索引没失效，但查出来的数据时间范围就是错的。这类问题在跨时区业务中特别普遍。最好的处理方式是在应用层先把时间统一转换成数据库时区，再放进 SQL。
另外，写 SQL 时尽量避免使用字符串拼接来构造条件。这不仅是因为拼接容易造成类型隐式转换，更是从安全角度考虑。无论你是写内部数据分析脚本，还是对外提供接口，参数化查询都应该成为默认习惯。很多注入类风险的本质，都是把外部输入直接当成 SQL 片段拼接，而不是把输入当成数据来传递。使用预编译语句、参数绑定等方式，既要更安全，也能减少因引号、转义字符引起的边界判断错误。
用 BETWEEN 时，参数化的好处同样明显：你可以在代码层面把 start 和 end 变量直接绑定为数值类型或日期类型，减少数据库做隐式转换的概率。遇到需要在字符串和日期之间转换的场景，也优先由驱动和数据库的绑定机制处理，而不是让 SQL 文本本身去猜。
6. 一张自检清单：BETWEEN 少数据、多数据、慢查询时先查什么
6.1 结果比预期少，先检查右边界和 NULL
我跟团队的同学说，遇到 BETWEEN 相关的问题，不要一上来就改 SQL，先别急着加各种乱七八糟的条件。冷静按下面的顺序排查，多半能快速定位。
如果查询结果比预期少，第一优先怀疑右边界没有覆盖到当天完整时间。比如查 3 月的数据，右边界写了 '2023-03-31'，而字段是 DATETIME，那 3 月 31 日白天和晚上的数据大概率丢失。第二优先怀疑 NULL。如果列里存在很多空值，并且期待空值也参与统计，BETWEEN 不会返回它们。这时就要想清楚，空值在业务上到底要不要出现在结果里。
如果查询结果比预期多，优先检查是否加了 OR 条件却没有括号，或者连接的等级区间有重叠，再检查字符串排序规则是否把本不想包含的大写/小写字符也圈进来了。这种多数据问题里，逻辑错误比边界错误更常见。
如果查询很慢，先跑 EXPLAIN。看到 type = ALL 或者 key = NULL，再回头检查字段类型和比较值类型是否一致、条件列有没有套函数、字符串列存的是否是日期语义。大部分 BETWEEN 性能问题都逃不出这三类原因。
6.2 实操中我固定使用的规则，直接抄就好
我把这些经验收敛成几个固定规则，每次写 BETWEEN 前都会自己在心里过一遍：
第一，先问字段类型。DATE 类型可以放心 BETWEEN；DATETIME/TIMESTAMP 类型，右边界改写成“下一天零点之前”的开区间更安全。
第二，先问列里有没有 NULL。如果有，明确要不要把空值单独拉出来处理，不要默认 SQL 会帮你把空值包含进去。
第三，先问区间是否相邻。做分桶统计或分档位 JOIN 时，左右相邻的区间要特别小心端点重复。给每个档位设计成下闭上开，是最稳妥的做法。
第四，如果 BETWEEN 两侧出现字符串，尤其是想表达字符串前缀范围，要提醒自己：这是字典序，不一定等于人眼理解的“字母区间”。
第五，慢查询排查时，把 BETWEEN 先改写成 >= 和 <=，再检查两边条件字段是否被函数包裹、类型是否一致。改写不是为了让 SQL 更快，而是为了让自己更容易看出问题。
拿这个清单回头看我最早讲的那个“少了 3 月 31 日数据”的例子，其实第二项规则就能直接命中：字段是 DATETIME，右边界只写到一个日期，没有补零点之后的时间段。如果当时写 SQL 的人使用 create_time >= '2023-03-01' AND create_time < '2023-04-01'，整个事故根本不会发生。
6.3 少在脑内模拟数据库行为，多让数据库自己告诉你答案
最后想分享一个我自己的习惯。很多 BETWEEN 的边界问题，靠人肉推理很容易绕晕。与其在不同时间精度、不同排序规则里反复猜测，不如直接写一段小的验证 SQL，让数据库把边界值打出来。比如我就经常用：
sql复制SELECT
CAST('2023-03-31' AS DATETIME) AS right_bound,
'2023-04-01' > '2023-03-31' AS string_compare_test;
这种临时查询不会影响任何业务数据，只是帮自己确认当前数据库的转换规则。尤其是要同时兼容 MySQL 和 PostgreSQL 的项目，字符串和日期之间的转换细节差异很大，靠记忆非常不靠谱。数据库文档写得再清楚，也不如在自己环境里跑一遍来得实在。
BETWEEN 这个语法本身很基础，但基础语法不等于没有陷阱。它背后连着的类型系统、索引机制、NULL 处理逻辑和排序规则，每一项都能让查询结果悄悄出现偏差。真正稳妥的用法，是不把它当语法背，而是当一套区间表达方法来理解：想清楚边界，想清楚类型，想清楚空值，再用自检清单快速筛查。做到这几点之后，无论是写报表还是做数据接口，在 BETWEEN 上踩坑的机会就会少很多。