尧图网站建设 
1. 项目概述为什么mapper.xml是MyBatis的灵魂如果你用过MyBatis那你肯定绕不开mapper.xml。很多人觉得它就是个写SQL的地方简单得很。但在我过去十多年的Java后端开发经历里踩过最多的坑、解决过最棘手的问题往往都藏在这些XML文件的细节里。面试时被问得最细的也常常是这里面的门道。它远不止是“写SQL”那么简单而是MyBatis框架数据操作能力的核心载体是连接Java对象和数据库表之间的桥梁和翻译官。简单来说mapper.xml定义了“做什么”SQL语句和“怎么做”输入输出映射、缓存、动态逻辑。一个设计良好的mapper.xml能让你的数据层代码清晰、高效且易于维护而一个混乱的mapper.xml则是性能瓶颈和隐蔽Bug的温床。今天我就结合自己趟过的坑把mapper.xml里的语法掰开揉碎了讲清楚从最基础的增删改查到复杂的动态SQL、高级映射再到那些官方文档里不会写的“实战心法”。无论你是刚接触MyBatis的新手还是想深入理解其工作原理的老手相信都能从中找到你需要的东西。2. mapper.xml文件结构与核心元素全解一个标准的mapper.xml文件其结构就像一棵树有根、有干、有枝叶。理解这个结构是写出规范文件的第一步。2.1 文档声明与命名空间每个mapper.xml文件都以一个标准的XML声明开头紧接着是mapper根元素。?xml version1.0 encodingUTF-8? !DOCTYPE mapper PUBLIC -//mybatis.org//DTD Mapper 3.0//EN http://mybatis.org/dtd/mybatis-3-mapper.dtd mapper namespacecom.example.dao.UserMapper !-- 具体的SQL映射语句写在这里 -- /mapper这里的namespace属性至关重要它必须指向对应的Mapper接口的全限定名。MyBatis就是通过这个命名空间将XML中的SQL语句与Java接口中的方法绑定起来的。一个常见的坑是namespace写错或者与接口名不对应导致BindingException。我建议在团队内强制约定将mapper.xml文件与Mapper接口放在同一目录下如src/main/resources/com/example/dao/并且文件名与接口名保持一致如UserMapper.xml这样可以借助IDE和Maven/Gradle的标准目录结构来避免这类低级错误。2.2 核心CRUD语句标签这是最常用的部分对应数据库的增删改查操作。select: 用于查询语句。select idselectUserById parameterTypeint resultTypecom.example.model.User SELECT id, username, email FROM user WHERE id #{id} /selectid: 对应Mapper接口中的方法名。parameterType: 传入参数的类型。基本类型如int,String可以写别名复杂类型写全限定类名。这个属性其实经常可以省略因为MyBatis可以通过反射自动推断。resultType: 返回结果的类型。如果字段名和对象属性名能自动映射驼峰转下划线通常可配置用这个最简单。但要注意如果查询结果包含多表关联的复杂对象resultType就力不从心了必须使用resultMap。insert: 用于插入语句。它有几个特有的属性。insert idinsertUser parameterTypecom.example.model.User useGeneratedKeystrue keyPropertyid INSERT INTO user(username, email) VALUES(#{username}, #{email}) /insertuseGeneratedKeys: 设置为true告知MyBatis使用JDBC的getGeneratedKeys方法来获取数据库内部生成的主键如自增ID。keyProperty: 指定将获取到的主键值赋值给参数对象的哪个属性。上面这个配置执行后传入的User对象的id属性就会被自动填充。update和delete: 用于更新和删除操作语法与select类似但没有resultType属性。update idupdateUser parameterTypecom.example.model.User UPDATE user SET username#{username}, email#{email} WHERE id#{id} /update delete iddeleteUserById parameterTypeint DELETE FROM user WHERE id #{id} /delete实操心得对于insert除了useGeneratedKeys在某些不支持自增主键或使用特殊主键生成策略如UUID的数据库场景下可以使用selectKey子标签来在插入前后执行一个SQL查询以获取或生成主键。这是一个进阶但非常实用的技巧。3. 参数传递与结果映射的深度解析这是MyBatis灵活性的核心体现也是容易混淆的地方。3.1 参数传递的多种姿势在SQL语句中我们使用#{}和${}来引用参数但它们有本质区别。#{}预编译占位符。MyBatis会将其替换为?然后通过PreparedStatement安全地设置参数。这是防止SQL注入的绝对首选。它会自动处理类型转换比如日期、字符串转义等。SELECT * FROM user WHERE username #{name} // 实际执行SELECT * FROM user WHERE username ? // 参数 ‘admin‘ 会被安全设置${}字符串直接替换。MyBatis会直接将参数值替换到SQL语句中。存在SQL注入风险除非你非常确信参数是安全的。它的适用场景是动态指定表名、列名等SQL语句本身的部分而非数据值。ORDER BY ${orderByColumn} -- 动态排序字段 SELECT * FROM ${tableName} -- 动态表名需谨慎传递多个参数时有三种主要方式使用实体类对象parameterType指定为实体类#{}中的名称对应实体类的属性名。最清晰、最常用。使用MapparameterType为map#{}中的名称对应Map的key。灵活但可读性差类型不安全。使用Param注解推荐在Mapper接口方法参数前加Param(“name”)注解然后在XML中直接使用#{name}引用。这是多简单参数传递的最佳实践。// Mapper接口 User selectByUsernameAndStatus(Param(username) String name, Param(active) Boolean status);!-- mapper.xml -- select idselectByUsernameAndStatus resultTypeUser SELECT * FROM user WHERE username #{username} AND is_active #{active} /select3.2 结果映射resultType与resultMapresultType自动映射。要求数据库列名或别名与Java对象属性名严格对应可通过mapUnderscoreToCamelCase配置开启驼峰自动转换。适用于简单查询。resultMap手动映射。功能强大可以处理任何复杂的映射关系。在以下场景必须使用resultMap列名与属性名无法自动对应。查询结果包含关联对象一对一、一对多。存在继承关系。需要进行类型处理器TypeHandler的定制。一个典型的resultMap定义如下resultMap iddetailedUserResultMap typecom.example.model.User !-- 主键映射 -- id propertyid columnuser_id/ !-- 普通属性映射 -- result propertyusername columnuser_name/ result propertyemail columnemail_address/ !-- 一对一关联 -- association propertyaddress javaTypecom.example.model.Address result propertystreet columnaddr_street/ /association !-- 一对多关联 -- collection propertyorderList ofTypecom.example.model.Order id propertyorderId columnorder_id/ result propertyorderNo columnorder_no/ /collection /resultMap select idselectUserWithDetails resultMapdetailedUserResultMap SELECT u.id as user_id, u.name as user_name, ..., a.street as addr_street, o.id as order_id, o.order_no FROM user u LEFT JOIN address a ON u.id a.user_id LEFT JOIN order o ON u.id o.user_id WHERE u.id #{id} /select避坑指南在定义复杂的collection时特别是“一对多”查询如果主表数据有重复直接使用JOIN会导致“N1查询”问题或结果集膨胀。MyBatis提供了One和Many注解的嵌套查询方式在association和collection中使用select属性可以转换为多次查询有时在数据量大时反而更高效。这需要根据实际数据量和数据库性能进行权衡。4. 动态SQL让SQL语句“活”起来动态SQL是MyBatis最强大的特性之一它允许我们在XML中编写条件逻辑生成不同的SQL语句完美解决了拼接SQL字符串的繁琐和安全隐患。4.1 核心动态SQL标签详解if条件判断。最常用的标签。select idfindUsers parameterTypemap resultTypeUser SELECT * FROM user WHERE 11 if testusername ! null and username ! AND username #{username} /if if testemail ! null AND email like CONCAT(%, #{email}, %) /if /selecttest属性内是OGNL表达式可以进行各种逻辑判断。注意这里的11是一个小技巧用于避免所有if都不成立时SQL语法错误WHERE后直接跟AND。但更好的做法是使用where标签。where/set/trim智能处理前缀/后缀。where会自动去除其内部首个SQL片段前的AND或OR并且如果其内部有内容才会插入WHERE关键字。完美解决11的尴尬。select idfindUsers resultTypeUser SELECT * FROM user where if testusername ! null AND username #{username} /if if testemail ! null AND email #{email} /if /where /selectset用于UPDATE语句动态更新列。它会自动去除末尾的逗号。update idupdateUserSelective parameterTypeUser UPDATE user set if testusername ! nullusername #{username},/if if testemail ! nullemail #{email},/if /set WHERE id #{id} /updatetrim功能更强大可以自定义要移除的前缀、后缀以及要添加的前缀、后缀。where和set本质上是trim的特定实现。choose,when,otherwise实现类似Java中的switch-case逻辑。select idfindActiveUser resultTypeUser SELECT * FROM user where choose when teststatus active AND status 1 AND login_date CURRENT_DATE - 30 /when when teststatus inactive AND status 0 /when otherwise AND status IN (1, 0) -- 默认查询所有状态 /otherwise /choose /where /selectforeach遍历集合常用于IN查询或批量操作。这是面试高频考点。!-- 批量查询 -- select idselectUsersByIdList resultTypeUser SELECT * FROM user WHERE id IN foreach itemid indexindex collectionidList open( separator, close) #{id} /foreach /select !-- 批量插入 (MySQL) -- insert idbatchInsertUsers parameterTypelist INSERT INTO user (username, email) VALUES foreach itemuser collectionlist separator, (#{user.username}, #{user.email}) /foreach /insertcollection: 传入的集合参数名。如果是List通常写list如果是Array写array或者使用Param注解指定的名字。item: 遍历时每个元素的别名。index: 遍历的索引可选。open/close/separator: 定义循环体开始、结束时的字符串以及元素间的分隔符。4.2 动态SQL的性能与可读性权衡动态SQL虽然方便但过度使用会导致XML文件臃肿可读性下降。我的经验是逻辑简单时优先用动态SQL标签清晰且安全。当条件组合非常复杂比如超过5个if嵌套时可以考虑在Java代码中构建查询条件或者使用MyBatis-Plus等增强工具的QueryWrapper将动态逻辑转移到类型安全的Java代码中。foreach批量操作时要注意数据库对单条SQL长度的限制。如果集合过大可能需要分批执行。例如可以写一个工具方法将大List拆分成每1000条执行一次批量插入。5. 高级特性与最佳实践掌握了基础我们再看一些提升效率和代码质量的高级用法和实战经验。5.1 SQL片段复用sql与include对于重复出现的SQL列集合或条件可以使用sql定义片段用include引用实现DRYDon‘t Repeat Yourself原则。!-- 定义可复用的列名片段 -- sql iduserBaseColumns id, username, email, create_time /sql sql iduserWhereCondition where is_deleted 0 if testusername ! nullAND username like #{username}/if /where /sql !-- 在多个查询中引用 -- select idselectAll resultTypeUser SELECT include refiduserBaseColumns/ FROM user include refiduserWhereCondition/ /select select idselectCount resultTypeint SELECT COUNT(1) FROM user include refiduserWhereCondition/ /select这极大地提高了可维护性。当表结构变更时只需修改一处sql定义。5.2 缓存配置一级与二级缓存MyBatis内置了缓存机制但理解不当会导致“脏读”问题。一级缓存SqlSession级别默认开启。在同一个SqlSession内执行相同的查询第二次会直接返回缓存的对象。注意一旦执行了增删改操作或者调用了sqlSession.clearCache()该SqlSession的所有一级缓存都会被清空。在Spring管理的环境下通常一个事务对应一个SqlSession事务结束即关闭所以一级缓存作用范围有限。二级缓存Mapper级别需要手动在mapper.xml中配置开启。mapper namespacecom.example.dao.UserMapper !-- 启用二级缓存 -- cache evictionLRU flushInterval60000 size512 readOnlytrue/ ... /mappereviction: 清除策略如LRU最近最少使用、FIFO等。flushInterval: 刷新间隔毫秒。size: 最多缓存对象数。readOnly: 是否只读。只读缓存性能更高但返回的是同一个对象实例修改它会影响到所有引用。严重警告二级缓存是基于namespace的多个Mapper操作同一张表时一个Mapper的更新可能不会使另一个Mapper的缓存失效导致脏数据。在分布式或高并发场景下使用二级缓存需要极其谨慎的设计甚至直接关闭转而使用Redis等集中式缓存。我个人在大多数生产项目中都会选择关闭二级缓存。5.3 实战中的“血泪”经验与排查技巧#{}与${}的误用这是安全红线。永远对用户输入的数据使用#{}。只有在动态表名、列名等非数据部分且参数完全可控时才考虑${}。结果映射的“N1”查询问题使用collection进行一对多关联查询时如果主表有N条记录关联查询可能会执行N1次1次查主表N次查关联表。解决方案使用collection的fetchType“lazy”进行懒加载按需查询。直接写一个多表连接的复杂SQL在resultMap中手动映射。这需要权衡单次查询复杂度与网络交互次数。在业务层分两次查询先查主表ID列表再批量查关联数据。这是很多互联网公司的常用做法。分页查询的性能陷阱使用LIMIT ?, ?进行分页时当offset非常大时如LIMIT 1000000, 20MySQL需要扫描大量数据然后丢弃性能极差。优化方案使用基于“上次最大ID”的查询WHERE id #{lastMaxId} LIMIT 20。使用覆盖索引子查询优化。考虑使用专门的分页插件如PageHelper它内部会尝试优化分页SQL。XML中的特殊字符XML中,,等是特殊字符。在SQL中写比较符号或AND、OR时要使用转义或![CDATA[ ]]包裹。!-- 错误 -- if testage 18 ... /if !-- ‘‘ 需要转义 -- !-- 正确 -- if testage gt; 18 ... /if !-- 或使用CDATA区 -- if testage 18 AND status 1 ![CDATA[ AND age 18 ]] /if调试SQLMyBatis最终执行的SQL和参数是看不到的。务必在开发环境开启MyBatis的SQL日志打印。在application.yml中配置logging: level: com.example.dao: DEBUG # 将你的Mapper接口所在包的日志级别设为DEBUG或者使用mybatis.configuration.log-implorg.apache.ibatis.logging.stdout.StdOutImpl。这样就能在控制台看到真实的、带参数的SQL是排查问题最直接的手段。6. 从xml到注解另一种选择与局限除了XMLMyBatis也支持使用Java注解直接在Mapper接口上定义SQL。例如Select(SELECT * FROM user WHERE id #{id}) User selectById(int id); Update(UPDATE user SET username#{username} WHERE id#{id}) int updateUser(User user); Insert(INSERT INTO user(username) VALUES(#{username})) Options(useGeneratedKeys true, keyProperty id) int insertUser(User user);注解方式非常简洁适合简单的、固定的SQL语句。但是注解方式有明确的局限性动态SQL支持弱虽然提供了SelectProvider,UpdateProvider等注解来调用一个SQL构建类但编写和维护复杂动态SQL的体验远不如XML直观。可读性差复杂的SQL写在注解字符串里换行、格式化都麻烦失去了高亮和结构。无法使用sql片段复用。因此我个人的最佳实践是简单的、静态的CRUD可以使用注解但凡涉及动态条件、复杂关联查询、结果映射一律使用XML配置。两者可以混用根据场景选择最合适的工具。最后关于mapper.xml的语法我想再强调一点它不仅仅是语法规则更是设计思维的体现。如何组织SQL片段、如何设计resultMap、如何编写高效且安全的动态SQL都直接关系到数据访问层的健壮性和性能。多读优秀的代码多思考不同场景下的最优解多利用日志进行调试和优化你就能真正驾驭MyBatis让它成为你手中高效、可靠的持久层利器。在那些需要处理复杂查询和高度定制化SQL的项目里精心编写的mapper.xml所带来的灵活性和控制力是任何全自动ORM框架都难以完全替代的。 MyBatis mapper.xml深度解析：从基础语法到高级实战技巧
1. 项目概述为什么mapper.xml是MyBatis的灵魂如果你用过MyBatis那你肯定绕不开mapper.xml。很多人觉得它就是个写SQL的地方简单得很。但在我过去十多年的Java后端开发经历里踩过最多的坑、解决过最棘手的问题往往都藏在这些XML文件的细节里。面试时被问得最细的也常常是这里面的门道。它远不止是“写SQL”那么简单而是MyBatis框架数据操作能力的核心载体是连接Java对象和数据库表之间的桥梁和翻译官。简单来说mapper.xml定义了“做什么”SQL语句和“怎么做”输入输出映射、缓存、动态逻辑。一个设计良好的mapper.xml能让你的数据层代码清晰、高效且易于维护而一个混乱的mapper.xml则是性能瓶颈和隐蔽Bug的温床。今天我就结合自己趟过的坑把mapper.xml里的语法掰开揉碎了讲清楚从最基础的增删改查到复杂的动态SQL、高级映射再到那些官方文档里不会写的“实战心法”。无论你是刚接触MyBatis的新手还是想深入理解其工作原理的老手相信都能从中找到你需要的东西。2. mapper.xml文件结构与核心元素全解一个标准的mapper.xml文件其结构就像一棵树有根、有干、有枝叶。理解这个结构是写出规范文件的第一步。2.1 文档声明与命名空间每个mapper.xml文件都以一个标准的XML声明开头紧接着是mapper根元素。?xml version1.0 encodingUTF-8? !DOCTYPE mapper PUBLIC -//mybatis.org//DTD Mapper 3.0//EN http://mybatis.org/dtd/mybatis-3-mapper.dtd mapper namespacecom.example.dao.UserMapper !-- 具体的SQL映射语句写在这里 -- /mapper这里的namespace属性至关重要它必须指向对应的Mapper接口的全限定名。MyBatis就是通过这个命名空间将XML中的SQL语句与Java接口中的方法绑定起来的。一个常见的坑是namespace写错或者与接口名不对应导致BindingException。我建议在团队内强制约定将mapper.xml文件与Mapper接口放在同一目录下如src/main/resources/com/example/dao/并且文件名与接口名保持一致如UserMapper.xml这样可以借助IDE和Maven/Gradle的标准目录结构来避免这类低级错误。2.2 核心CRUD语句标签这是最常用的部分对应数据库的增删改查操作。select: 用于查询语句。select idselectUserById parameterTypeint resultTypecom.example.model.User SELECT id, username, email FROM user WHERE id #{id} /selectid: 对应Mapper接口中的方法名。parameterType: 传入参数的类型。基本类型如int,String可以写别名复杂类型写全限定类名。这个属性其实经常可以省略因为MyBatis可以通过反射自动推断。resultType: 返回结果的类型。如果字段名和对象属性名能自动映射驼峰转下划线通常可配置用这个最简单。但要注意如果查询结果包含多表关联的复杂对象resultType就力不从心了必须使用resultMap。insert: 用于插入语句。它有几个特有的属性。insert idinsertUser parameterTypecom.example.model.User useGeneratedKeystrue keyPropertyid INSERT INTO user(username, email) VALUES(#{username}, #{email}) /insertuseGeneratedKeys: 设置为true告知MyBatis使用JDBC的getGeneratedKeys方法来获取数据库内部生成的主键如自增ID。keyProperty: 指定将获取到的主键值赋值给参数对象的哪个属性。上面这个配置执行后传入的User对象的id属性就会被自动填充。update和delete: 用于更新和删除操作语法与select类似但没有resultType属性。update idupdateUser parameterTypecom.example.model.User UPDATE user SET username#{username}, email#{email} WHERE id#{id} /update delete iddeleteUserById parameterTypeint DELETE FROM user WHERE id #{id} /delete实操心得对于insert除了useGeneratedKeys在某些不支持自增主键或使用特殊主键生成策略如UUID的数据库场景下可以使用selectKey子标签来在插入前后执行一个SQL查询以获取或生成主键。这是一个进阶但非常实用的技巧。3. 参数传递与结果映射的深度解析这是MyBatis灵活性的核心体现也是容易混淆的地方。3.1 参数传递的多种姿势在SQL语句中我们使用#{}和${}来引用参数但它们有本质区别。#{}预编译占位符。MyBatis会将其替换为?然后通过PreparedStatement安全地设置参数。这是防止SQL注入的绝对首选。它会自动处理类型转换比如日期、字符串转义等。SELECT * FROM user WHERE username #{name} // 实际执行SELECT * FROM user WHERE username ? // 参数 ‘admin‘ 会被安全设置${}字符串直接替换。MyBatis会直接将参数值替换到SQL语句中。存在SQL注入风险除非你非常确信参数是安全的。它的适用场景是动态指定表名、列名等SQL语句本身的部分而非数据值。ORDER BY ${orderByColumn} -- 动态排序字段 SELECT * FROM ${tableName} -- 动态表名需谨慎传递多个参数时有三种主要方式使用实体类对象parameterType指定为实体类#{}中的名称对应实体类的属性名。最清晰、最常用。使用MapparameterType为map#{}中的名称对应Map的key。灵活但可读性差类型不安全。使用Param注解推荐在Mapper接口方法参数前加Param(“name”)注解然后在XML中直接使用#{name}引用。这是多简单参数传递的最佳实践。// Mapper接口 User selectByUsernameAndStatus(Param(username) String name, Param(active) Boolean status);!-- mapper.xml -- select idselectByUsernameAndStatus resultTypeUser SELECT * FROM user WHERE username #{username} AND is_active #{active} /select3.2 结果映射resultType与resultMapresultType自动映射。要求数据库列名或别名与Java对象属性名严格对应可通过mapUnderscoreToCamelCase配置开启驼峰自动转换。适用于简单查询。resultMap手动映射。功能强大可以处理任何复杂的映射关系。在以下场景必须使用resultMap列名与属性名无法自动对应。查询结果包含关联对象一对一、一对多。存在继承关系。需要进行类型处理器TypeHandler的定制。一个典型的resultMap定义如下resultMap iddetailedUserResultMap typecom.example.model.User !-- 主键映射 -- id propertyid columnuser_id/ !-- 普通属性映射 -- result propertyusername columnuser_name/ result propertyemail columnemail_address/ !-- 一对一关联 -- association propertyaddress javaTypecom.example.model.Address result propertystreet columnaddr_street/ /association !-- 一对多关联 -- collection propertyorderList ofTypecom.example.model.Order id propertyorderId columnorder_id/ result propertyorderNo columnorder_no/ /collection /resultMap select idselectUserWithDetails resultMapdetailedUserResultMap SELECT u.id as user_id, u.name as user_name, ..., a.street as addr_street, o.id as order_id, o.order_no FROM user u LEFT JOIN address a ON u.id a.user_id LEFT JOIN order o ON u.id o.user_id WHERE u.id #{id} /select避坑指南在定义复杂的collection时特别是“一对多”查询如果主表数据有重复直接使用JOIN会导致“N1查询”问题或结果集膨胀。MyBatis提供了One和Many注解的嵌套查询方式在association和collection中使用select属性可以转换为多次查询有时在数据量大时反而更高效。这需要根据实际数据量和数据库性能进行权衡。4. 动态SQL让SQL语句“活”起来动态SQL是MyBatis最强大的特性之一它允许我们在XML中编写条件逻辑生成不同的SQL语句完美解决了拼接SQL字符串的繁琐和安全隐患。4.1 核心动态SQL标签详解if条件判断。最常用的标签。select idfindUsers parameterTypemap resultTypeUser SELECT * FROM user WHERE 11 if testusername ! null and username ! AND username #{username} /if if testemail ! null AND email like CONCAT(%, #{email}, %) /if /selecttest属性内是OGNL表达式可以进行各种逻辑判断。注意这里的11是一个小技巧用于避免所有if都不成立时SQL语法错误WHERE后直接跟AND。但更好的做法是使用where标签。where/set/trim智能处理前缀/后缀。where会自动去除其内部首个SQL片段前的AND或OR并且如果其内部有内容才会插入WHERE关键字。完美解决11的尴尬。select idfindUsers resultTypeUser SELECT * FROM user where if testusername ! null AND username #{username} /if if testemail ! null AND email #{email} /if /where /selectset用于UPDATE语句动态更新列。它会自动去除末尾的逗号。update idupdateUserSelective parameterTypeUser UPDATE user set if testusername ! nullusername #{username},/if if testemail ! nullemail #{email},/if /set WHERE id #{id} /updatetrim功能更强大可以自定义要移除的前缀、后缀以及要添加的前缀、后缀。where和set本质上是trim的特定实现。choose,when,otherwise实现类似Java中的switch-case逻辑。select idfindActiveUser resultTypeUser SELECT * FROM user where choose when teststatus active AND status 1 AND login_date CURRENT_DATE - 30 /when when teststatus inactive AND status 0 /when otherwise AND status IN (1, 0) -- 默认查询所有状态 /otherwise /choose /where /selectforeach遍历集合常用于IN查询或批量操作。这是面试高频考点。!-- 批量查询 -- select idselectUsersByIdList resultTypeUser SELECT * FROM user WHERE id IN foreach itemid indexindex collectionidList open( separator, close) #{id} /foreach /select !-- 批量插入 (MySQL) -- insert idbatchInsertUsers parameterTypelist INSERT INTO user (username, email) VALUES foreach itemuser collectionlist separator, (#{user.username}, #{user.email}) /foreach /insertcollection: 传入的集合参数名。如果是List通常写list如果是Array写array或者使用Param注解指定的名字。item: 遍历时每个元素的别名。index: 遍历的索引可选。open/close/separator: 定义循环体开始、结束时的字符串以及元素间的分隔符。4.2 动态SQL的性能与可读性权衡动态SQL虽然方便但过度使用会导致XML文件臃肿可读性下降。我的经验是逻辑简单时优先用动态SQL标签清晰且安全。当条件组合非常复杂比如超过5个if嵌套时可以考虑在Java代码中构建查询条件或者使用MyBatis-Plus等增强工具的QueryWrapper将动态逻辑转移到类型安全的Java代码中。foreach批量操作时要注意数据库对单条SQL长度的限制。如果集合过大可能需要分批执行。例如可以写一个工具方法将大List拆分成每1000条执行一次批量插入。5. 高级特性与最佳实践掌握了基础我们再看一些提升效率和代码质量的高级用法和实战经验。5.1 SQL片段复用sql与include对于重复出现的SQL列集合或条件可以使用sql定义片段用include引用实现DRYDon‘t Repeat Yourself原则。!-- 定义可复用的列名片段 -- sql iduserBaseColumns id, username, email, create_time /sql sql iduserWhereCondition where is_deleted 0 if testusername ! nullAND username like #{username}/if /where /sql !-- 在多个查询中引用 -- select idselectAll resultTypeUser SELECT include refiduserBaseColumns/ FROM user include refiduserWhereCondition/ /select select idselectCount resultTypeint SELECT COUNT(1) FROM user include refiduserWhereCondition/ /select这极大地提高了可维护性。当表结构变更时只需修改一处sql定义。5.2 缓存配置一级与二级缓存MyBatis内置了缓存机制但理解不当会导致“脏读”问题。一级缓存SqlSession级别默认开启。在同一个SqlSession内执行相同的查询第二次会直接返回缓存的对象。注意一旦执行了增删改操作或者调用了sqlSession.clearCache()该SqlSession的所有一级缓存都会被清空。在Spring管理的环境下通常一个事务对应一个SqlSession事务结束即关闭所以一级缓存作用范围有限。二级缓存Mapper级别需要手动在mapper.xml中配置开启。mapper namespacecom.example.dao.UserMapper !-- 启用二级缓存 -- cache evictionLRU flushInterval60000 size512 readOnlytrue/ ... /mappereviction: 清除策略如LRU最近最少使用、FIFO等。flushInterval: 刷新间隔毫秒。size: 最多缓存对象数。readOnly: 是否只读。只读缓存性能更高但返回的是同一个对象实例修改它会影响到所有引用。严重警告二级缓存是基于namespace的多个Mapper操作同一张表时一个Mapper的更新可能不会使另一个Mapper的缓存失效导致脏数据。在分布式或高并发场景下使用二级缓存需要极其谨慎的设计甚至直接关闭转而使用Redis等集中式缓存。我个人在大多数生产项目中都会选择关闭二级缓存。5.3 实战中的“血泪”经验与排查技巧#{}与${}的误用这是安全红线。永远对用户输入的数据使用#{}。只有在动态表名、列名等非数据部分且参数完全可控时才考虑${}。结果映射的“N1”查询问题使用collection进行一对多关联查询时如果主表有N条记录关联查询可能会执行N1次1次查主表N次查关联表。解决方案使用collection的fetchType“lazy”进行懒加载按需查询。直接写一个多表连接的复杂SQL在resultMap中手动映射。这需要权衡单次查询复杂度与网络交互次数。在业务层分两次查询先查主表ID列表再批量查关联数据。这是很多互联网公司的常用做法。分页查询的性能陷阱使用LIMIT ?, ?进行分页时当offset非常大时如LIMIT 1000000, 20MySQL需要扫描大量数据然后丢弃性能极差。优化方案使用基于“上次最大ID”的查询WHERE id #{lastMaxId} LIMIT 20。使用覆盖索引子查询优化。考虑使用专门的分页插件如PageHelper它内部会尝试优化分页SQL。XML中的特殊字符XML中,,等是特殊字符。在SQL中写比较符号或AND、OR时要使用转义或![CDATA[ ]]包裹。!-- 错误 -- if testage 18 ... /if !-- ‘‘ 需要转义 -- !-- 正确 -- if testage gt; 18 ... /if !-- 或使用CDATA区 -- if testage 18 AND status 1 ![CDATA[ AND age 18 ]] /if调试SQLMyBatis最终执行的SQL和参数是看不到的。务必在开发环境开启MyBatis的SQL日志打印。在application.yml中配置logging: level: com.example.dao: DEBUG # 将你的Mapper接口所在包的日志级别设为DEBUG或者使用mybatis.configuration.log-implorg.apache.ibatis.logging.stdout.StdOutImpl。这样就能在控制台看到真实的、带参数的SQL是排查问题最直接的手段。6. 从xml到注解另一种选择与局限除了XMLMyBatis也支持使用Java注解直接在Mapper接口上定义SQL。例如Select(SELECT * FROM user WHERE id #{id}) User selectById(int id); Update(UPDATE user SET username#{username} WHERE id#{id}) int updateUser(User user); Insert(INSERT INTO user(username) VALUES(#{username})) Options(useGeneratedKeys true, keyProperty id) int insertUser(User user);注解方式非常简洁适合简单的、固定的SQL语句。但是注解方式有明确的局限性动态SQL支持弱虽然提供了SelectProvider,UpdateProvider等注解来调用一个SQL构建类但编写和维护复杂动态SQL的体验远不如XML直观。可读性差复杂的SQL写在注解字符串里换行、格式化都麻烦失去了高亮和结构。无法使用sql片段复用。因此我个人的最佳实践是简单的、静态的CRUD可以使用注解但凡涉及动态条件、复杂关联查询、结果映射一律使用XML配置。两者可以混用根据场景选择最合适的工具。最后关于mapper.xml的语法我想再强调一点它不仅仅是语法规则更是设计思维的体现。如何组织SQL片段、如何设计resultMap、如何编写高效且安全的动态SQL都直接关系到数据访问层的健壮性和性能。多读优秀的代码多思考不同场景下的最优解多利用日志进行调试和优化你就能真正驾驭MyBatis让它成为你手中高效、可靠的持久层利器。在那些需要处理复杂查询和高度定制化SQL的项目里精心编写的mapper.xml所带来的灵活性和控制力是任何全自动ORM框架都难以完全替代的。