不要使用IService。IService 封装了数据访问层的逻辑，实际上就应该属于业务访问层， 而且使用IService打破了表示层、业务逻辑层、数据访问层三层模型，将数据访问层的逻辑转移到业务逻辑层， 导致我们的Service对象变得异常臃肿。

尽量使用lambda链式处理。使用函数式参数避免了字符串拼写的问题，不过由于我们并不使用IService，Query并不能完全链式表示，比如还要显示调用 selectOne(query) 等方法。

不要使用联表查询。虽然MP支持了一定程度的联表查询，但是终究支持有限，不利用后续优化。使用 xml 即可，mybatis 对于 1对多、多对多的支持就很好。

不要使用MP提供的逻辑删除。在实际业务中我们常常使用逻辑删除，即把对数据的删除改为标记删除位。MP的逻辑删除不支持唯一索引的使用，我们需要自己实现逻辑删除。 对于一条用户信息，email字段是唯一的，UNIQUE INDEX unique_email (email) 这样设置索引是有问题的，因为我们可能有多条已经逻辑删除的邮箱。 解决方法是引入额外的字段保证唯一，常见的方法是引入uuid，对于并发量不大的业务也可以用时间戳， UNIQUE INDEX unique_email (email, delete_flag)。详见后续代码。

熟练使用条件构造器。官网提供了条件构造器的详细说明，熟练使用可以极大提高写代码的效率。

可以通过继承通用接口 BaseMapper 实现代码复用。也有人通过对于QueryMapper的封装实现复用；还可以通过组合对象的方式，由于Mapper对象由代理生成， 我们通过委托（Delegate) 实现对到具体的Mapper的调用。