在diboot 2.0版本框架的封装过程中，我们遇到的问题和最终的解决方案也许可以给此时的你提供些帮助和思路，于是就有了这些系列文章。此系列主题为“Mybatis单表CRUD与多表关联的无SQL实现方案”，目的是给出一套简单灵活易用的通用方案，可以做到1.利用通用Mapper框架实现单表CRUD无SQL，2.封装基于注解的多表关联自动绑定的无SQL实现方案。
一、Mybatis的CRUD通用解决方案
为什么需要通用Mapper？
Mybatis中针对一个单表的CRUD操作一般要在其对应Mapper中写SQL，表的字段名会多次出现，当字段变更，增减时都需要同步修改其Mapper，繁琐且易出错。针对于单表的CRUD是比较简单的，可以在Entity中将字段与数据库表的列进行绑定，然后借助一个通用Mapper实现通用的CRUD，这样针对单表CRUD的操作将不再需要写SQL。
通用Mapper框架的选择
Mybatis-plus v3.x版本除了提供通用Mapper之外，还具备了方便易用的基于Lambda的条件构造器以及逻辑删除乐观锁等解决方案。
另外也有其他轻量级的通用Mapper实现，比如Mapper 4.x，也是一个通用Mapper框架的选择。
用上了通用Mapper，感觉越像JPA了？
如果只是单表的CRUD，通用mapper方案确实跟JPA类似，不过JPA在Java代码里写SQL和对于复杂查询的处理不便，都带来了开发维护的麻烦。依然选用Mybatis方案，既借助通用Mapper实现了类似JPA的单表处理便利性，又保留了Mybatis自定义SQL的灵活性优势。
多表关联如何处理？
对于多表关联的处理，通用Mapper并没有给出较好的解决方案，你可以通过自定义SQL关联查询绑定，每个都要去写SQL，这样很繁琐。另外一个方案就是类似JPA的通过注解绑定表关联关系，然后实现查询结果的绑定。这个方案可以将关联查询拆解成多个单表查询，然后根据绑定关系组装最终结果，后续我们通过自定义封装实现这个方案，按需定制你的关联绑定方案。
至于为何要将关联查询拆解成单表查询，可以到<高性能MySQL>一书中了解分解关联查询的好处。
概括来讲，优点 如下：
- 让缓存的效率更高，缓存的利用率会越高，效率当然就会越好。关联查询如果某个表发生变化，就无法使用缓存了。
- 将查询分解后，执行单个查询可以减少锁的竞争。
- 在应用层做关联，可以更容易的对数据库进行拆分，更容易做到高性能和高扩展性。
- 查询本身效率也会提升。
- 可以减少冗余记录的查询。
- 更进一步，这样做相当于在应用中实现了哈希关联，而不是使用mysql的嵌套循环关联。某些场景哈希关联的效率要高很多。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。