写SQL查数据的时候，十个人里有八个第一反应是写，剩下那两个可能直接用了。这玩意儿看着简单，可坑也不少。今天不聊高深的优化器原理，就掰开揉碎讲讲这个语法到底怎么用、什么时候千万别用。
先说最基本的语法结构。是SQL标准里的范围查询运算符，写法是，它等价于。注意，这里是闭区间，两头都包含。很多人第一次用的时候以为它是开区间，结果查出来的数据比预期多了一行，回头排查半天才发现是边界问题。比如你查，那18岁和30岁的人都会被捞出来，一个不多一个不少。
这个语法最大的好处是 readability，代码读起来像人话。你写，任何人一看就懂，不用在脑子里做逻辑换算。相比之下，写成也不是不行，但多变量组合的时候，括号一多，人眼就容易花。尤其是团队协作的时候，别人review你的代码，一眼扫过去能立刻明白查询意图，这比什么都重要。
不过，别急着高兴，这玩意儿有个隐蔽的坑：它跟索引的关系。如果你的查询条件里只用了，数据库优化器通常能走索引范围扫描，性能没毛病。但如果你在的字段上套了函数，比如，索引就废了，全表扫描跑起来，数据量大点直接卡死。所以记住一条铁律：的字段必须是裸字段，别包函数，别做运算，否则性能给你颜色看。
再说说数据类型敏感这事。对数据类型的匹配要求很严格。你查日期字段，写，看起来没问题，但如果是带时分秒的时间戳类型，那会被隐式转换成，也就是说，12月31号当天下午三点产生的数据根本查不出来。很多线上bug就是这么来的。解决办法要么用和配合下一天零点，要么用把字段转成纯日期，别指望数据库替你聪明。
还有个容易忽略的点：的下限必须小于等于上限，否则返回空集。这听起来是废话，但实际开发中，前端传参经常把范围搞反，比如日期选择器用户选了结束日期早于开始日期，后端直接拿参数去拼SQL，结果查出来一片空白，用户还以为系统坏了。正经做法是在业务层先做参数校验，或者干脆在SQL里用和包一层，保证顺序正确。
再说说。这个写法是，语义上等价于。注意，这里没有闭区间的问题，因为不等号天然排除了边界。但有个坑是，如果字段里有值，的行不会被查出来。因为参与比较的结果是，子句只保留的行。所以你想用过滤掉某个范围，结果发现也一起消失了，数据对不上，排查半天才意识到是空值在捣鬼。
聊到这儿，得说说和的区别。是等值匹配，适合离散值列表，比如。是范围匹配，适合连续数值或时间区间。两者混用的时候要小心，比如你写，逻辑没问题，但可读性已经下降了。更推荐的做法是，连续范围用，离散枚举用，各司其职，别硬混。
给个实战建议。写的时候，养成一个好习惯：在注释里标明边界包含关系。因为不同数据库对日期和字符串的处理有微调，比如MySQL和PostgreSQL在某些边界情况下行为不一致。你在代码里写一行，三个月后自己回来看代码，或者同事接手，都能少踩一个坑。另外，如果查询的是时间区间，强烈建议用和的组合替代，比如，这样既走索引，又不丢边界数据，两全其美。
总结一句：是个好工具，但它是给懂边界的人用的。你搞清楚它的闭区间特性、数据类型的隐式转换、索引匹配规则，它就是你SQL工具箱里一把锋利的刀。搞不清楚这些，它就是割手的刀片。下次写范围查询的时候，先问自己三件事：字段类型是什么？边界值要不要包含？有没有可能传反参数？想清楚了再写，比什么都强。
