Mybatis及MybatisPlus

简介: 本文系统介绍MyBatis核心架构与常用功能,涵盖配置流程、结果集映射、参数传递、XML配置项、缓存机制及分页插件应用,并简要介绍MyBatis Plus的常用API,助力高效开发。

1、系统架构流程

执行过程:

  1. mybatis配置

mybatis-config.xml,名称可变,此文件作为mybatis的全局配置文件,配置了mybatis的运行环境等信息。mapper.xml文件即sql映射文件,文件中配置了操作数据库的sql语句。此文件需要在mybatis-config.xml中加载;

  1. 通过mybatis环境等配置信息构造SqlSessionFactory即会话工厂;
  2. 由会话工厂创建sqlSession即会话,操作数据库需要通过sqlSession进行;
  3. mybatis底层自定义了Executor执行器接口操作数据库,Executor接口有两个实现,一个是基本执行器、一个是缓存执行器;
  4. Mapped Statement也是mybatis一个底层封装对象,它包装了mybatis配置信息及sql映射信息等。mapper.xml文件中一个sql对应一个Mapped Statement对象,sql的id即是Mapped statement的id;
  5. Mapped Statement对sql执行输入参数进行定义,包括HashMap、基本类型、pojo,Executor通过 Mapped Statement在执行sql前将输入的java对象映射至sql中,输入参数映射就是jdbc编程中对preparedStatement设置参数;
  6. Mapped Statement对sql执行输出结果进行定义,包括HashMap、基本类型、pojo,Executor通过 Mapped Statement在执行sql后将输出结果映射至java对象中,输出结果映射过程相当于jdbc编程中对结果的解析处理过程。

2、结果集映射

在 MyBatis 中,结果集映射是指将查询数据库得到的结果集映射到 Java 对象的过程。MyBatis 提供了 XML 配置和注解两种方式来进行结果集映射。

1)使用xml的方式;则可以使用 resultTyperesultMap ;其中 resultType可以直接指定类名即可。而 resultMap可以映射更加复杂的映射关系;包括 一对一(可以使用 association )、一对多(可以使用 collection )等复杂的关联关系。

2)使用注解的方式;可以使用 @Select@Result 配合使用。

3、mapper传参

在 MyBatis 中,Mapper 接口中定义的方法可以接受参数来进行数据库操作。Mapper 方法可以接受多种类型的参数,包括基本数据类型、Java 对象、Map 等。

1、在mapper接口中的方法形参前面使用 @Param 指定名称;然后在映射文件或者@Select 注解内直接使用 #{} 或者 ${} 获取;

2、不使用 @Param ;那么直接在需要使用的sql语句中,参数的名称要写成 param1,param2。。。

3、如果传递的是一个对象或者map类型;那么在sql也可以直接使用对象或map的属性或key名称

4、xml常用配置

MyBatis 的 XML 配置文件中包含了许多常用的配置项,这些配置项可以帮助你定义映射关系、SQL 查询、参数传递等。以下是一些 MyBatis XML 配置中常用的配置:

1)数据源配置:配置连接数据库的信息,包括驱动类、URL、用户名和密码等。

2)映射器配置:指定映射器文件或映射器接口的位置。

3)类型别名配置:为 Java 类型指定别名,简化映射器文件中的使用。

4)结果映射配置:定义 SQL 查询结果与 Java 对象之间的映射关系。

5)SQL 查询配置:编写 SQL 查询语句,并指定参数类型、返回结果类型等。

6)参数传递配置:定义方法参数传递方式,可以使用基本类型、Java 对象、Map 等作为参数。

5、缓存机制

MyBatis 提供了两级缓存(Local Cache 和 Second Level Cache)来满足不同的需求。

1、Local Cache(本地缓存、一级缓存)

  • Local Cache 是指在 SqlSession 范围内的缓存,它默认开启并且无法关闭。
  • 在同一个 SqlSession 中,当执行相同的查询语句(包括参数相同)时,如果之前已经查询过相同的结果,那么会直接从本地缓存中获取数据,而不会再发送 SQL 查询到数据库。
  • Local Cache 是基于 HashMap 实现的,它仅在当前 SqlSession 中有效,并且对于不同的 SqlSession 是隔离的。

2、Second Level Cache(二级缓存)

  • Second Level Cache 是指在 Mapper 范围内的缓存,它可以跨 SqlSession 共享数据。
  • 如果开发者需要使用 Second Level Cache,需要在映射文件中进行配置。
  • 当开启了 Second Level Cache 后,同一个 namespace 下的查询结果会被缓存起来,其他 SqlSession 也可以共享这部分数据,从而减少数据库查询次数。
  • Second Level Cache 默认是关闭的,需要手动在映射文件中配置开启。

6、分页插件

MyBatis 中常见的分页插件有: PageHelperMyBatis Plus 都是用于简化分页查询操作的工具,它们能够大大简化分页查询的代码编写,并提供了丰富的分页功能。两类插件都是基于Mybatis的拦截器实现;所以需要在使用之前添加对应的拦截器。而在使用的时候:

  • PageHelper中使用的参考: `
PageHelper.startPage(页号, 页大小);
  • MybatisPlus中的使用参考:
IPage<User> userPage = userService.page(new Page<>(页号, 页大小));

7、Mybatis-Plus常用API

MyBatis Plus 是在 MyBatis 的基础上进行增强的工具,提供了丰富的 API 来简化数据访问层的开发。常见的api有如下图:

相关文章
|
1天前
|
Java 测试技术 API
从Google线上故障,谈灰度发布的重要性
2025年6月12日,Google Cloud因未灰度发布的配置导致全球服务中断7小时。根因是新功能缺乏错误处理,触发空指针异常,暴露了配置管理的重大风险。本文详解配置灰度发布策略,并以Nacos为例,介绍基于IP和标签的灰度实现方案,强调渐进式发布对系统稳定性的重要性。
从Google线上故障,谈灰度发布的重要性
|
1天前
|
存储 缓存 监控
EFC&CTO:缓存引发数据不一致问题排查与深度解析
EFC客户端在NAS场景下因缓存版本号回退,导致读取旧数据覆盖正常内容,引发CTO测试数据不一致。通过日志分析与复现实验,定位为分布式缓存中dv版本管理缺陷所致,修复后验证问题解决。
 EFC&CTO:缓存引发数据不一致问题排查与深度解析
|
1天前
|
Java Linux 开发工具
Linux
本文介绍如何将一个SpringBoot项目打包并部署到Linux服务器。内容涵盖工程搭建、jar包打包、JDK安装配置、应用上传与启动,以及通过心跳接口验证服务是否正常运行的完整流程,适用于Java应用的Linux部署学习与实践。
|
1天前
|
自然语言处理 fastjson Java
FastJson:大面积故障规避案例
本文记录了一次由Kotlin语法误用引发的FastJson反序列化重大故障。因将 `{}` 错误赋值给 Java 对象字段,导致 FastJson 解析时触发 `kotlin_error` 静态标记位异常,进而使整个工程反序列化链路瘫痪。问题根源隐蔽,排查耗时两天,最终通过深入源码定位解决。反映出多语言混编下语法混淆风险及对第三方框架过度依赖的隐患,强调代码严谨性与灰度发布的重要性。
 FastJson:大面积故障规避案例
|
1天前
|
运维 NoSQL 测试技术
Redis:内存陡增100%深度复盘
本次事故因大KEY调用量随流量增长,导致带宽占满100%,Redis内存在5分钟内从0%升至100%,最终引发全面超时崩溃。根本原因为缓冲区(输入/输出)内存激增,占用超限,使Redis无法正常处理请求。尽管数据淘汰机制存在,但对缓冲区内存无效,最终导致服务不可用。需优化Key设计、合理配置缓冲区及加强压测监控。
Redis:内存陡增100%深度复盘
|
1天前
|
消息中间件 监控 Java
RocketMQ:底层Netty频繁OS OOM
本文记录了一例Java应用因Netty多ClassLoader加载导致堆外内存超限引发OS OOM的排查过程。根本原因为多个中间件通过不同ClassLoader加载了独立的PooledByteBufAllocator实例,各自绕过JVM直接内存限制,致使总占用远超MaxDirectMemorySize。结合Arthas、NMT等工具分析定位,最终确认RocketMQ客户端为主要内存消耗者,并提出短期调整堆内存配比、长期优化中间件的解决方案。
|
1天前
|
监控 Java 测试技术
OOM排查之路:一次曲折的线上故障复盘
本文记录了一次Paimon数据湖与RocksDB集成服务频繁OOM的排查历程。通过分析线程激增、堆外内存泄漏,最终定位到RocksDB JNI内存未释放问题,并借助Flink重构写入链路彻底解决。分享了MAT、NMT、async-profiler等工具的实战经验与系统性排查思路,为类似场景提供借鉴。(239字)
 OOM排查之路:一次曲折的线上故障复盘
|
1天前
|
测试技术 索引 NoSQL
5-MongoDB实战演练
本文介绍某头条文章评论功能的设计与实现,基于MongoDB构建微服务。内容涵盖需求分析、表结构设计、技术选型(SpringDataMongoDB)、实体类编写、增删改查、分页查询及点赞功能优化,使用MongoTemplate实现高效字段更新,提升系统性能。
 5-MongoDB实战演练
|
1天前
|
存储 缓存 运维
一场FullGC故障排查
本文记录了一次由Full GC引发的CPU使用率异常问题排查过程。通过分析JVM堆内存,发现大对象(List&lt;Map&gt;)导致老年代频繁被占满,进而触发Full GC,最终定位到代码中Excel数据加载逻辑存在内存膨胀问题,并提出优化方案。
|
1天前
|
NoSQL MongoDB Linux
2-MongoDB单机部署
本文详细介绍MongoDB在Windows和Linux系统中的安装与启动步骤,包括下载地址、版本选择、解压配置、命令行及配置文件启动方法,并介绍Shell连接、图形化工具Compass的使用,以及Linux下的服务部署、防火墙设置和安全关闭方式,附带各环境安装包下载链接。
 2-MongoDB单机部署