WHERE 1=1 是恒真占位符，用于简化动态SQL条件拼接，避免判断首个条件；但需配合参数化绑定防注入、白名单控结构、NULL逻辑校验及索引优化，推荐用MyBatis 标签或条件构造器替代。
WHERE 1=1 本身不参与业务过滤，它只是个恒真占位符，作用是让后续所有条件都能统一用 AND 拼接，省去判断“是否为第一个条件”的逻辑。但它只是拼接便利的“拐杖”，不是安全或高性能的解决方案——真正关键的是如何组织结构、校验输入、绑定参数。
为什么从 WHERE 1=1 开始拼接？
动态查询常面临这样的问题：用户可能只选姓名，也可能同时选姓名+状态+时间范围，甚至一个都不选。如果不用 1=1，就得每次检查 WHERE 是否已存在：
- 一个条件：SELECT * FROM users WHERE name = ?
- 两个条件：SELECT * FROM users WHERE name = ? AND status = ?
- 零个条件：SELECT * FROM users（不能带 WHERE）
而用 WHERE 1=1 后，所有分支都只需追加 AND 条件，代码更线性、不易出错：
- SELECT * FROM users WHERE 1=1
- SELECT * FROM users WHERE 1=1 AND name = ?
- SELECT * FROM users WHERE 1=1 AND name = ? AND status = ?
- SELECT * FROM users WHERE 1=1（返回全表，但语法合法）
必须避开的三大陷阱
单纯拼接 1=1 很容易滑向高危实践，尤其在存储过程或字符串拼接场景中：
- SQL 注入风险：若直接把用户输入拼进 SQL 字符串（如 CONCAT(' AND name = "', @name, '"')），遇到 O'Connor 或 '; DROP TABLE -- 就会执行恶意语句
- 空值逻辑错误：AND id = NULL 永远不成立（NULL 不能用 = 判断），应改用 IS NULL；未判空就拼条件，会导致结果意外为空
- 索引失效隐患：虽然 1=1 本身不影响执行计划，但若后续条件因拼接不当写成 LIKE '%xxx%' 或函数包裹字段（如 UPPER(name) = ?），就会跳过索引
安全又实用的组装方式（推荐）
核心是分清「结构」和「数据」：表名、字段名属于结构，必须白名单控制；查询值属于数据，必须参数化绑定。
-
应用层（如 Java）：用 StringBuilder 拼接时，WHERE 1=1 可接受，但所有值一律用 ? 占位符，由框架（如 MyBatis 的
标签、JDBC PreparedStatement）自动绑定参数 -
MyBatis 场景：直接用
标签替代 WHERE 1=1 —— 它会智能添加 WHERE 关键字，并自动剔除开头多余的 AND/OR，更干净且无注入风险 - 存储过程（MySQL）：禁用字符串拼接值；改用 PREPARE + EXECUTE 配合参数占位符（?），例如 SET @sql = 'SELECT * FROM users WHERE 1=1'; IF p_name IS NOT NULL THEN SET @sql = CONCAT(@sql, ' AND name LIKE ?'); END IF; SET @stmt = @sql; EXECUTE @stmt USING p_name;
替代 WHERE 1=1 的更优思路
当追求更高可维护性或规避任何潜在歧义时，可完全绕开 1=1：
- 用集合收集条件片段（如 List
clauses），最后用 StringUtils.join(clauses, " AND ") 拼接，空集合时生成无 WHERE 的语句 - ORM 框架中启用条件构造器（如 QueryDSL、JPA Criteria API），由对象模型驱动 SQL 生成，天然隔离拼接逻辑
- 数据库端用视图或 CTE 预定义基础查询，再通过参数控制 FILTER 逻辑，减少动态拼接层级
