QueryWrapper的lt方法为何对空值或null字段查询失效？

Question

在使用 MyBatis-Plus 的 `QueryWrapper.lt("column", value)` 进行小于条件查询时，若数据库中目标字段存在 `NULL` 值，这些记录**默认不会被查出**——因为 SQL 中 `NULL < 5` 返回的是 `UNKNOWN`（非 `TRUE`），不满足 `WHERE` 条件。这是 SQL 标准行为，而非 QueryWrapper 的 Bug。`lt` 方法仅生成形如 `column < ?` 的 SQL 片段，未额外处理 NULL 逻辑。开发者常误以为“所有数据都应参与比较”，却忽略 NULL 在三值逻辑中的特殊性。若需包含 NULL 记录，须显式追加 `or().isNull("column")`；若需排除 NULL 再比较，应前置 `and().isNotNull("column")`。该问题在统计、导出、分页等场景易引发数据遗漏，建议在涉及可空字段的范围查询时，始终审视 NULL 处理策略。

Answer 1

```html

一、现象层：为什么 QueryWrapper.lt("age", 18) 查不到 age 为 NULL 的记录？

这是最直观的困惑起点。开发者执行如下代码：

QueryWrapper<User> wrapper = new QueryWrapper<>();
wrapper.lt("age", 18);
List<User> minors = userMapper.selectList(wrapper);

但数据库中存在 age IS NULL 的用户（如未填写年龄的注册用户），这些记录不会出现在结果中。原因并非 MyBatis-Plus “漏掉了”，而是底层生成的 SQL 为：
WHERE age < ? —— 而根据 SQL 标准，NULL < 18 的求值结果是 UNKNOWN，而 WHERE 子句仅接受 TRUE 的行。

二、原理层：SQL 三值逻辑与 NULL 的语义本质

NULL 在 SQL 中不是值，而是“缺失值”（missing value）的标记。它不参与常规比较运算，所有涉及 NULL 的二元比较（<, =, > 等）均返回 UNKNOWN。这与 Java 中 null == null 返回 false 或 NullPointerException 有根本区别。

表达式	SQL 结果	说明
NULL < 5	UNKNOWN	不满足 WHERE 条件
NULL = NULL	UNKNOWN	需用 IS NULL 判断
NOT (NULL > 10)	UNKNOWN	NOT 不翻转 UNKNOWN

三、框架层：MyBatis-Plus 的设计契约与责任边界

MyBatis-Plus 的 QueryWrapper.lt() 是严格遵循 SQL 语义的“忠实翻译器”——它只做一件事：将 Java 方法调用映射为标准 SQL 比较片段，不做隐式 NULL 补偿。这是其设计哲学的体现：不封装 SQL 复杂性，避免“魔法行为”导致的不可预测性。它假设开发者具备基础 SQL 素养，并明确知晓字段可空性。

若强行在 lt() 内部追加 OR column IS NULL，将违反最小惊讶原则（Principle of Least Astonishment），且破坏跨数据库兼容性（如某些 OLAP 引擎对 NULL 的处理略有差异）。

四、实践层：三种典型 NULL 处理策略及对应代码模式

针对不同业务语义，应选择显式、可读、可维护的组合方式：

• 策略A（含 NULL）：视 NULL 为“符合任意范围条件” → wrapper.lt("age", 18).or().isNull("age")
• 策略B（排 NULL）：仅对已知数值进行比较 → wrapper.and(q -> q.isNotNull("age").lt("age", 18))
• 策略C（NULL 优先）：NULL 排最前，再按数值排序 → 需配合 orderBy 与数据库方言（如 MySQL ORDER BY age IS NULL DESC, age）

五、架构层：如何在团队工程中系统性规避 NULL 陷阱？

单靠个人经验不足以保障质量。建议构建三层防御：

1. 建模层：在实体类字段上使用 @TableField(fill = FieldFill.INSERT) 或非空约束注解（如 @NotBlank），配合 Lombok @Builder.Default 设默认值；
2. DAO 层：封装领域专用 Wrapper 工具类，例如 RangeQueryWrapper<T> 提供 ltInclusiveNull() 等语义化方法；
3. 测试层：强制要求单元测试覆盖 NULL 数据路径（如 H2 内存库插入 NULL 后断言 size）。

六、演进层：从 MyBatis-Plus 到现代数据访问范式的启示

该问题折射出 ORM 抽象的固有张力：越贴近 SQL，越可控；越远离 SQL，越易失真。近年趋势正走向“显式优于隐式”——如 jOOQ 的 DSL.field("age").lt(18).or(DSL.field("age").isNull())，或 Spring Data JPA 的 @Query 原生 SQL + 参数绑定。MyBatis-Plus 的轻量级 Wrapper 正是这一思潮的早期实践者。

七、可视化决策流：NULL 处理路径选择图

graph TD A[查询需求] --> B{业务语义中
NULL 是否等价于
“满足条件”？} B -->|是| C[使用 or().isNull()] B -->|否| D{是否允许 NULL
参与统计/分页？} D -->|否| E[前置 and().isNotNull()] D -->|是| F[保留原 lt()，但文档注明 NULL 被过滤] C --> G[生成 SQL: col < ? OR col IS NULL] E --> H[生成 SQL: col IS NOT NULL AND col < ?]

```