1.2 选型与使用边界

本章只提供定性选型参考。启动时间、代码行数和吞吐量受项目规模、版本、数据库和测试方法影响；在没有可复现 benchmark 前，不在官方文档中给出“快多少倍”或固定秒数。

定性对比

维度	DLZ-DB	MyBatis/MyBatis-Plus	JPA	jOOQ
主要风格	DB.* 静态门面 + Wrapper	Mapper + SQL/XML/注解/Wrapper	Repository + 对象关系映射	生成代码 + SQL DSL
简单 CRUD	无需自写 Mapper	MP 可减少 CRUD 样板	Repository 支持完整	DSL 表达
复杂 SQL	DB.jdbc 或预设 DB.sql	MyBatis SQL/XML/注解	JPQL/Criteria/Native SQL	类型安全 DSL
动态表/数据源	DB.table / DB.ds 显式切换	通常需要插件或项目封装	通常需要 EntityManager/多持久化单元配置	通过 DSLContext/连接配置
框架集成	Spring Boot、Solon	主要为 Spring 生态	主要为 Jakarta/Spring 生态	框架无关，可与 Spring 等集成
关联/对象图	不自动管理，显式 SQL	MyBatis 显式映射	核心能力	以 SQL/记录为主
成熟生态	较小	大	大	成熟

DLZ-DB 适合的场景

• 项目愿意使用静态 DB.* 门面，并希望减少 Mapper/DAO 样板。
• 业务以单表 CRUD 为主，复杂查询可以显式使用 SQL。
• 需要在 Spring Boot 和 Solon 之间复用核心数据库 API。
• 需要运行时动态注册、切换数据源，并接受“单数据源本地事务”边界。

应优先评估其他方案的场景

• 依赖完整的对象关系级联、脏检查、一级缓存和持久化上下文：优先评估 JPA/Hibernate。
• 希望复杂 SQL 的列、表和返回记录获得大规模编译期类型安全：优先评估 jOOQ。
• 已经有大量成熟 Mapper/XML、插件与团队经验：继续使用 MyBatis/MyBatis-Plus 可能风险更低。
• 要求成熟的多租户、分库分表、分布式事务或完整迁移生态：应以可验证的专门组件为准，不要仅依赖 DLZ-DB 的本地数据源切换。

DLZ-DB 当前硬边界

• Wrapper 主要面向单表；JOIN、CTE、UNION、窗口函数和复杂聚合使用 DB.jdbc/DB.sql。
• DB.ds.use 不开启事务；DB.tx 只提供单数据源本地事务。
• 自动更新表结构不是 Flyway/Liquibase 的完整替代，生产环境应关闭 helper.auto-update。
• 内置方言映射不等于所有数据库版本都经过完整集成测试。
• 性能与其他框架的差异需要用自己的 SQL、数据集、连接池和运行环境 benchmark。