如何实现SQL中的非等值查询：逻辑运算符与范围设置
说到SQL查询，等值匹配（=）大家都很熟悉。但很多时候，业务需求没那么“精确”，你需要的是“大于某个值”、“在某个区间内”或者“符合某种模式”。这时候，就得请出非等值查询了。它的核心逻辑很简单：放弃等号，改用其他运算符来表达更灵活的关系。不过，这里面门道不少，从基础的比较运算符到棘手的NULL处理，每一步都有细节需要注意。
WHERE 中用 <、>、BETWEEN 做非等值过滤
最直观的非等值查询，莫过于使用比较运算符：<、>、<=、>=。另一个高频选手是BETWEEN ... AND ...，它专门用来划定一个范围。
这里有个关键细节：BETWEEN是闭区间。也就是说，BETWEEN 10 AND 20这个条件，会包含10和20这两个边界值。如果你想要更清晰的表达，或者未来可能调整为半开区间（比如包含10但不包含20），直接用>= 10 AND <= 20这种写法会更灵活。
当然，这几个运算符用起来也有讲究：
BETWEEN的可读性陷阱：在查日期或数值范围时，BETWEEN确实一目了然。但它有个天生缺陷——不能用来判断NULL。像BETWEEN NULL AND 100这样的条件，结果永远是UNKNOWN，不会返回任何行。- 字符串比较的“潜规则”：用
<、>比较字符串时，结果完全取决于数据库的排序规则（collation）。'apple' < 'banana'通常成立，但'Apple' < 'apple'呢？如果排序规则区分大小写，那结果可就未必了。 - 性能上的考量：如果字段上没有建立合适的索引，那么执行
>或<这类范围查询时，数据库很可能被迫进行全表扫描。其性能开销，通常会比等值查询大得多。
用 IN 和 NOT IN 实现离散值非等值匹配
IN运算符看起来像是在做“等值”匹配，比如status IN ('active', 'pending')。但从逻辑分类上讲，它属于典型的非等值分支——它表达的是“属于某个给定集合”，而非“等于某个单一值”。
真正需要打起精神的是NOT IN，尤其是当它遇到NULL的时候。举个例子：status NOT IN ('active', 'pending')。如果数据表中某条记录的status字段恰好是NULL，那么这条记录不会被包含在结果集里。原因在于，NULL NOT IN (...)的求值结果是UNKNOWN，而非TRUE。
怎么绕开这个坑？有几个常用策略：
- 显式排除NULL：最直接的方法是加上
IS NOT NULL条件，写成status IS NOT NULL AND status NOT IN ('active', 'pending')。 - 换用其他逻辑：考虑使用
NOT EXISTS或者外连接（OUTER JOIN）来重写查询，通常能获得更清晰、更可控的逻辑。 - 注意列表长度：使用
IN时，列表里的值不宜过多。不同数据库有不同限制（例如Oracle默认限制1000项），即使没有硬性限制，过长的列表也会导致性能急剧下降。
处理 NULL 时非等值判断必须显式写 IS NULL 或 IS NOT NULL
在SQL的世界里，NULL是个特殊存在。它与任何值（包括它自己）的比较，结果都是UNKNOWN。这意味着，当你写下age != 25时，那些age为NULL的行会被静默地过滤掉，因为它们不满足“不等于25”这个条件（结果不是TRUE）。
所以，如果你想在非等值逻辑中正确处理NULL，就必须把它当作一个独立的状态来显式处理：
- 包含NULL的查询：如果想找出“年龄不是25岁的人”，并且希望包含年龄未知的记录，应该写成：
age != 25 OR age IS NULL。 - 排除NULL的查询：如果只想找出“年龄明确不是25岁”的人，那么直接用
age != 25就可以了，因为NULL会被自然排除。 - 牢记铁律：永远不要尝试用
age <> NULL或age = NULL来判断。根据SQL标准，判断NULL的唯一正确方式是使用IS NULL或IS NOT NULL。
用 LIKE 和正则实现模式层面的非等值匹配
当查询条件从精确值变成某种模式时，LIKE和正则表达式（如REGEXP）就派上用场了。它们本质上也是非等值匹配，判断的是“是否符合某种模式”，而非“是否完全相等”。但它们的陷阱往往更多，主要集中在性能和语义差异上。
常见的问题往往不是语法错误，而是索引失效和通配符使用不当：
- 索引失效场景：
name LIKE '%son'这种以后缀为条件的查询，通常无法利用普通的B-tree索引。除非使用专门的倒排索引，或者像PostgreSQL的pg_trgm这类扩展。 - 通配符的位置：
name LIKE 'John%'（前缀匹配）一般可以使用索引，但要注意数据库的排序规则是否区分大小写，这会影响匹配结果。 - 正则表达式的“方言”：不同数据库的正则表达式引擎实现有差异。例如
REGEXP '^[A-Z]+'在MySQL和PostgreSQL中的行为可能不同（比如是否默认启用多行模式）。 - 性能警告：尽量避免在
WHERE子句中对大文本字段（如TEXT类型）进行复杂的正则匹配，这很容易成为查询的性能瓶颈。
说到底，非等值查询的难点不在于记住那几个运算符，而在于真正理解每个运算符在边界情况下的行为——尤其是面对NULL、空字符串、不同字符集以及索引支持的时候。一个很好的习惯是：写完查询后，顺手用EXPLAIN命令看一下执行计划。当数据量增长后，这个习惯能帮你提前发现很多潜在的性能问题。
