QBE不是SQL替代品，而是通过填空生成SQL的交互工具，适合单表多字段筛选，但不支持JOIN、子查询、聚合等复杂操作。
QBE 是什么，它真能替代写 SQL 吗
qbe（query by example）不是 sql 替代品，而是用“填空”方式生成 sql 的交互逻辑。它适合快速筛选、组合字段条件，但不支持 join、子查询、聚合函数等复杂操作。一旦你点开“高级模式”或看到 join 字段变灰、group by 不可选，说明 qbe 已退化为单表 where 构建器。
常见错误现象：点击添加关联表后条件消失、输入 AVG(price) 报错 Expression not allowed。这不是 bug，是设计限制——QBE 的底层只做字段值匹配映射，不解析表达式语义。
- 适用场景：后台管理列表页的多字段模糊搜索（如“姓名含‘张’且状态=启用且创建时间在 2024-01-01 后”）
- 不适用场景：统计类报表、跨业务域关联（如“查每个部门下薪资高于平均值的员工”）
- 性能影响：QBE 生成的 SQL 通常带
LIKE '%xxx%'和多个AND，无索引字段会全表扫描；手动加EXPLAIN看执行计划比依赖界面提示更可靠
字段值怎么填才不会被当成字符串字面量
QBE 的“填空”本质是模板替换，填的内容直接拼进 SQL 的 WHERE 子句。填 100 会被当数字，填 100% 就变成 LIKE '100%'，填 NULL 可能被转成 = 'NULL' 而非 IS NULL。
关键规则：QBE 框架对空值、通配符、范围语法有固定识别模式，不是所有写法都生效。
- 空值必须填
IS NULL或勾选“为空”复选框（取决于前端实现），填null/None/ 留空 都可能失效 - 模糊匹配用
%关键词%，但有些系统只认前缀关键词%或后缀%关键词，填错会导致索引失效 - 日期范围要填成
2024-01-01 .. 2024-12-31（双点分隔），填BETWEEN ... AND ...会被当字符串原样拼入 - 布尔字段填
true/false多数有效，但老系统可能只认1/0或Y/N
多个条件之间到底是 AND 还是 OR
绝大多数 QBE 实现默认行内字段是 AND，不同行之间也是 AND——这是最常被误读的一点。想表达“姓名是张三 或 李四”，不能分两行填，必须用单行填 张三|李四（如果支持管道符），或切换到“条件组”模式手动拖拽逻辑块。
错误现象：填了两行 name = 张三 和 name = 李四，结果查不到任何数据，实际生成的是 WHERE name = '张三' AND name = '李四'，永远为假。
- 确认当前工具是否支持条件组（常见于低代码平台，叫“添加逻辑块”“嵌套条件”等）
- 不支持时，用数据库原生支持的 OR 写法：某些系统接受
张三,李四（逗号分隔）表示IN，但需后端显式解析，不是通用行为 - 避免混用：同一字段既填值又勾“为空”，多数 QBE 会忽略后者或报冲突
导出的 SQL 为什么和预期不一致
QBE 导出的 SQL 常含隐式转换、冗余括号、字段别名缺失，甚至漏掉 ESCAPE 字符处理 LIKE 中的下划线。这不是导出功能坏了，而是 QBE 生成器为了兼容性做了保守处理。
典型差异：导出显示 WHERE status = 'active' AND created_at > '2024-01-01'，但实际执行时 created_at 是 TIMESTAMP 类型，而界面填的日期没带时分秒，导致查不到当天数据。
- 导出后务必人工检查：时间字段是否补了
00:00:00和23:59:59，字符串是否加了转义（如_前加\） - 某些框架（如 Apache Cayenne）导出的 SQL 会把
id IN (1,2,3)拆成三个OR，大数据量时性能骤降 - 别直接复制导出 SQL 到生产环境执行——它没经过参数化，存在注入风险，尤其当你填的内容里有单引号
QBE 的边界很清晰：它是给非 SQL 用户搭的脚手架，不是 SQL 编辑器。越想绕过它的限制，越容易掉进生成逻辑和数据库语义错位的坑里。
