1. 项目概述为什么我们需要一份MyBatis XML的“生存手册”干了这么多年Java后端MyBatis绝对是绕不开的老朋友。尤其是它的XML映射文件说它是项目里的“定海神针”一点不为过。但就是这个看似简单的.xml文件坑起人来毫不手软。我见过太多团队项目初期为了赶进度SQL写得飞起各种${}直接拼接参数动态SQL逻辑嵌套得比俄罗斯套娃还复杂。等到项目要上线做安全扫描奇安信这类工具一跑满屏的“SQL注入漏洞”告警直接让人头皮发麻。或者是在高并发场景下一个没写好的动态条件查询因为参数为空导致全表扫描性能瞬间雪崩。更别提那些因为resultMap配置不当导致的数据映射错误或是模糊查询时因为参数处理不当引发的诡异问题。所以我决定整理这份“常用总结”。它不是什么官方文档的复刻而是我这些年踩过坑、填过坑后沉淀下来的实战经验合集。目的很明确当你接手一个老项目或者自己写代码时感觉心里没底打开这份总结能快速找到那个“标准答案”和“避坑指南”。我会围绕最核心、最常用、也最容易出错的点展开比如动态SQL的#{}和${}到底怎么选才能既安全又灵活resultMap如何优雅地处理复杂关联以及如何写出既高效又安全的CRUD语句。这份总结是“持续更新”的因为技术和最佳实践也在变我会把遇到的新问题、新解法不断补充进来。2. 核心基石深入理解MyBatis XML的配置与映射在开始写复杂的动态SQL之前我们必须把地基打牢。MyBatis XML的核心配置元素每一个都有其明确的职责和需要注意的细节理解它们是写出稳健代码的第一步。2.1 映射文件的结构与核心元素一个标准的MyBatis Mapper XML文件通常遵循以下结构。这不仅仅是格式更是一种逻辑组织。?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就是通过这个namespace将XML中的SQL语句与Java接口中的方法绑定起来的。如果这里写错运行时就会报“BindingException”告诉你找不到对应的语句。接下来文件体内主要包含以下几类元素select、insert、update、delete 对应CRUD操作。每个元素都有一个唯一的id属性这个id就是接口中对应的方法名。sql 用于定义可重用的SQL片段。这是提升XML可维护性的关键工具避免重复代码。resultMap 定义数据库结果集到Java对象属性的复杂映射规则。当字段名和属性名不一致或者存在一对一、一对多关联时必须使用它。parameterMap 老式参数映射现在基本已被Param注解和直接在SQL中使用#{}的方式取代不推荐使用。2.2#{}与${}的天壤之别安全与灵活性的抉择这是MyBatis面试必问也是实际开发中最容易埋雷的地方。两者的区别本质上就是“预编译”和“字符串拼接”的区别。#{}预编译占位符MyBatis在处理#{}时会将其替换为JDBC的?占位符然后通过PreparedStatement来赋值。这个过程是预编译的。优点绝对防止SQL注入因为参数值是在预编译后才传入的不会被解释为SQL指令的一部分。这是应对奇安信等安全扫描的最根本手段。自动类型处理MyBatis会根据参数对象的类型自动进行java.util.Date到java.sql.Date等转换。通常不需要处理引号对于字符串参数MyBatis会自动加上引号。示例SELECT * FROM user WHERE name #{name}会被编译为SELECT * FROM user WHERE name ?然后安全地传入参数值。${}字符串替换MyBatis在处理${}时会直接将其中的内容作为字符串拼接到SQL语句中。风险SQL注入漏洞如果${}中的内容是用户可控的输入如搜索关键词恶意用户输入 OR 11就会导致严重的注入攻击。这正是安全扫描工具会报警的地方。需要手动处理引号和类型拼接字符串需要你自己考虑是否加单引号数字类型则不能加。适用场景非常有限且需谨慎动态表名或列名例如根据参数动态选择查询哪张表。SELECT * FROM ${tableName}。必须确保tableName的值来自可信的枚举或配置绝对不能让用户输入。ORDER BY子句动态排序字段如ORDER BY ${orderByField} ${orderByType}。同样需要对参数值进行严格的白名单校验。核心原则默认永远使用#{}。仅在不得不使用${}的场景下且对参数值进行严格的、可信的校验和过滤后才考虑使用。在99%的WHERE条件参数传递中都应该用#{}。2.3 ResultMap对象映射的艺术当数据库查询返回的结果无法通过简单的自动映射字段名属性名完成时resultMap就是你的利器。基础字段映射resultMap idBaseResultMap typecom.example.model.User id propertyid columnuser_id/ !-- 主键字段建议用id -- result propertyusername columnuser_name/ result propertyemail columnemail_address/ !-- 如果属性名和列名相同可以省略但显式声明更清晰 -- /resultMapid标签用于指定主键字段有助于提高性能如缓存标识。property对应Java对象属性column对应数据库列名。处理关联关系一对一一对多 这是ResultMap真正强大的地方。假设一个User拥有多个Order。resultMap idUserWithOrdersResultMap typeUser extendsBaseResultMap !-- 一对多关联一个用户有多个订单 -- collection propertyorderList ofTypeOrder fetchTypelazy id propertyorderId columnorder_id/ result propertyorderNo columnorder_no/ result propertyamount columnamount/ !-- 订单对象中可能还有关联可以继续嵌套 -- /collection /resultMapcollection用于映射一对多关系。property是User类中的ListOrder orderList属性名ofType是集合中元素的类型。fetchTypelazy表示延迟加载这是一个非常重要的性能优化点。只有在代码中真正访问user.getOrderList()时MyBatis才会执行查询订单的SQL。默认情况下MyBatis的关联是延迟加载的但通过fetchType可以显式控制。高级技巧association与复杂联合查询对于一对一关联如一个订单对应一个发货地址使用association。resultMap idOrderDetailResultMap typeOrder association propertydeliveryAddress javaTypeAddress result propertycity columnaddr_city/ result propertystreet columnaddr_street/ /association /resultMap对于复杂的、需要连接多个表的查询可以在SQL中使用JOIN然后在ResultMap中通过association或collection的column和columnPrefix属性精细地映射来自不同表的、可能有列名重复的结果集。这比发起多次查询N1问题通常性能更高。3. 动态SQL构建灵活且安全的查询体系动态SQL是MyBatis XML的灵魂它允许我们根据运行时条件来动态拼接SQL语句避免编写大量重复且难以维护的if-elseJava代码。但能力越大责任越大动态SQL也是最容易写出性能问题和安全漏洞的地方。3.1 核心标签详解与应用场景if条件判断最常用的标签用于在满足条件时包含某段SQL。select idfindUsers resultMapBaseResultMap SELECT * FROM user WHERE 11 !-- 避免WHERE后面直接跟AND的技巧但并非最优 -- if testusername ! null and username ! AND username LIKE CONCAT(%, #{username}, %) /if if testemail ! null AND email #{email} /if /selecttest属性内是OGNL表达式可以直接使用参数对象的属性进行判断。注意字符串空值判断username ! 。where、set、trim智能处理前缀where智能处理WHERE子句。它会自动删除开头多余的AND或OR并且只有在子元素有返回内容时才会插入WHERE关键字。这是处理动态条件的最佳实践可以抛弃11这种取巧但影响可读性和性能的写法。select idfindUsers resultMapBaseResultMap SELECT * FROM user where if testusername ! null AND username #{username} /if if testemail ! null AND email #{email} /if /where /selectset用于UPDATE语句智能处理SET子句自动删除末尾多余的逗号。update idupdateUserSelective UPDATE user set if testusername ! nullusername #{username},/if if testemail ! nullemail #{email},/if if teststatus ! nullstatus #{status},/if /set WHERE id #{id} /updatetrim更通用的标签可以自定义要添加的前缀、后缀以及要删除的前缀、后缀。where和set都可以用trim来实现它提供了最高的灵活性。!-- 等价于 where -- trim prefixWHERE prefixOverridesAND |OR ... /trim !-- 等价于 set -- trim prefixSET suffixOverrides, ... /trimchoose,when,otherwise多路选择类似于Java中的switch-case用于实现互斥的条件选择。select idfindActiveUsers resultMapBaseResultMap SELECT * FROM user where choose when teststatus ACTIVE AND status ACTIVE AND last_login_time #{recentDate} /when when teststatus INACTIVE AND status INACTIVE /when otherwise AND status IS NOT NULL !-- 默认条件 -- /otherwise /choose /where /selectforeach遍历集合这是处理IN查询和批量操作的利器。常见场景根据一组ID查询用户或批量插入数据。!-- 查询ID在指定列表中的用户 -- select idfindUsersByIds resultMapBaseResultMap SELECT * FROM user WHERE id IN foreach collectionidList itemid indexindex open( separator, close) #{id} /foreach /selectcollection: 传入的参数集合属性名。如果接口方法参数是List通常写list如果用了Param(ids)则写ids。item: 遍历时的每个元素的变量名。open/close: 循环体开始和结束时添加的字符串。separator: 元素之间的分隔符。批量插入示例insert idbatchInsertUsers INSERT INTO user (username, email) VALUES foreach collectionuserList itemuser separator, (#{user.username}, #{user.email}) /foreach /insert注意MySQL对单条SQL的长度有限制max_allowed_packet。当userList非常大时直接拼接成一条巨型SQL可能导致报错。在实际生产中需要对大列表进行分批次处理例如每1000条执行一次插入。3.2 参数传递与OGNL表达式技巧动态SQL的test属性中使用的OGNL表达式非常强大。判断集合是否为空if testlist ! null and list.size() 0或更简洁的if testlist ! null and !list.isEmpty()。这是处理foreach前必须做的防御性判断否则可能运行时报错。字符串判断除了判空还可以判断是否包含特定字符串如if testname ! null and name.contains(admin)。数值比较if testage ! null and age gt 18(gt表示大于)。调用静态方法可以通过全限定类名方法名调用静态方法但需谨慎使用因为会降低SQL的可移植性。参数传递的几种方式单个简单类型参数在SQL中可以直接使用#{参数名}但为了清晰建议使用Param注解。多个参数必须使用Param(name)注解然后在XML中通过#{name}引用。JavaBean对象直接使用属性名如#{username}。Map通过key来引用如#{mapKey}。传递ListString参数这是热词中提到的一个具体问题。在接口中定义为ListString types在XML的foreach中collection直接写typesitem写type即可。如果参数是Map中的一个List则需要写collectionmapKey。4. 高级特性与性能优化实战掌握了基础我们来看看如何让MyBatis XML用得更高效、更强大。这部分内容往往决定了应用在高负载下的表现。4.1 缓存机制深度解析MyBatis提供了一级缓存和二级缓存。理解它们是进行性能调优的基础。一级缓存SqlSession级别范围默认开启在同一个SqlSession通常对应一次数据库会话/事务内有效。行为执行查询后结果会被缓存。在同一个SqlSession中再次执行完全相同的SQL和参数时会直接返回缓存对象而不会再次访问数据库。失效时机执行了INSERT、UPDATE、DELETE操作任何写操作。手动调用sqlSession.clearCache()。执行了其他会导致缓存失效的查询如查询不同的命名空间。SqlSession被关闭。注意事项一级缓存可能导致“脏读”。例如在同一个SqlSession中你先查询了一个用户然后在另一个方法中修改了该用户但未提交此时再查询得到的仍是缓存中的旧数据。在涉及多个操作的复杂业务中需要留意。二级缓存Mapper级别/命名空间级别范围需要手动在XML中配置开启作用于整个Mapper命名空间可以被多个SqlSession共享。配置mapper namespacecom.example.dao.UserMapper cache evictionLRU flushInterval60000 size512 readOnlytrue/ !-- 其他语句 -- /mappereviction缓存回收策略如LRU最近最少使用、FIFO先进先出。flushInterval缓存刷新间隔毫秒到期后缓存清空。size最多可以存储的对象数。readOnly是否为只读。只读缓存性能更高但返回的是缓存对象的引用修改它们会影响缓存。非只读false会返回序列化后的副本更安全但性能稍差。工作机制当一个SqlSession关闭或提交时其查询结果才会被存入二级缓存。另一个SqlSession查询时如果命中缓存则直接返回。使用陷阱与建议实体类必须实现Serializable接口因为二级缓存可能将数据存储到磁盘或跨进程。查询语句的useCache和flushCache属性可以细粒度控制单个语句是否使用缓存(useCachetrue)或执行后是否刷新缓存(flushCachetrue)。对于更新频繁的数据可以考虑关闭其缓存。缓存共享问题如果多个Mapper操作同一张表且都开启了二级缓存需要小心缓存数据不一致。可以通过cache-ref来让多个Mapper共享同一个缓存实例但这增加了复杂度。分布式环境默认的基于内存的二级缓存在分布式环境下无效。生产环境通常会集成Redis等分布式缓存作为二级缓存实现。个人心得对于读远多于写、且数据实时性要求不高的配置表、字典表开启二级缓存收益明显。对于核心业务表尤其是写操作频繁的我通常不建议开启二级缓存维护缓存一致性的成本可能高于其带来的性能收益。一级缓存通常够用且更可控。4.2 分页查询的演进与最佳实践分页是高频操作其实现方式直接影响性能和用户体验。1. 原始Limit分页适合简单场景select idfindUsersByPage resultMapBaseResultMap SELECT * FROM user ORDER BY create_time DESC LIMIT #{offset}, #{pageSize} /select简单直接但在数据量极大offset非常大时MySQL需要扫描大量数据然后丢弃性能很差。2. 基于“上一页最大ID”的分页性能最优这是一种“seek method”利用索引的有序性避免OFFSET的大规模扫描。select idfindUsersAfterId resultMapBaseResultMap SELECT * FROM user WHERE id #{lastMaxId} !-- 假设id是自增主键且有序 -- ORDER BY id ASC LIMIT #{pageSize} /select这种方式性能极佳但限制是只能“下一页”查询不支持直接跳到任意页码。适合瀑布流、无限滚动加载的场景。3. 使用MyBatis分页插件如PageHelper这是国内最流行的方案。通过在查询方法前调用PageHelper.startPage(pageNum, pageSize)插件会自动拦截后续的查询SQL为其加上分页语句如LIMIT并同时执行一个COUNT(*)查询获取总记录数封装到PageInfo对象中。优点使用极其方便功能强大支持多种数据库提供PageInfo包含总页数、当前页等丰富信息。注意事项确保PageHelper.startPage()紧跟要分页的查询语句中间不要有其它查询否则会被错误拦截。分页语句是插件动态添加的要确保原SQL是支持分页的简单查询没有UNION、存储过程等复杂结构。对于超大数据量的COUNT(*)操作可能很慢可以考虑用其他方式估算总数或者使用“不查询总数”的模式。4. 数据库原生分页如Oracle的ROWNUMSQL Server的OFFSET FETCH原理类似写法因数据库而异。MyBatis分页插件通常能自动识别数据库类型并生成正确的分页SQL。4.3sql片段与include提升可维护性当多个查询语句中有重复的SQL片段时如复杂的字段列表、通用的查询条件使用sql定义片段再用include引用可以极大提升可维护性。!-- 定义可重用的列名片段 -- sql idBase_Column_List id, username, email, create_time, status /sql !-- 定义可重用的查询条件片段 -- sql idWhere_Active where status ACTIVE if testdepartmentId ! null AND department_id #{departmentId} /if /where /sql !-- 在查询中引用 -- select idselectActiveUsers resultMapBaseResultMap SELECT include refidBase_Column_List/ FROM user include refidWhere_Active/ ORDER BY create_time DESC /select这样做的好处是当表结构变更如字段名修改或公共查询逻辑变化时只需修改一处sql定义即可。5. 安全编码、疑难排查与性能调优这一章是我们经验的结晶很多都是线上真实踩过的坑。掌握了这些你写出的MyBatis XML才真正具备生产级可靠性。5.1 严防SQL注入从编码到扫描的防御体系安全无小事尤其是在奇安信等安全扫描成为标配的今天。根本大法坚持使用#{}。再次强调所有来自用户输入、外部接口、甚至内部非绝对可信源的参数在拼接进WHERE、SET、VALUES、HAVING等子句时必须使用#{}。这是第一道也是最重要的防线。审慎使用${}并施加白名单校验。如果业务上确实需要动态表名、列名或排序字段必须对${}中的变量值进行严格校验。!-- 危险的写法 -- ORDER BY ${sortField} ${sortOrder} !-- 相对安全的写法需在Java代码或XML中校验 --对应的Java代码或XML中的if测试应确保sortField只能是允许的字段名枚举如create_time,usernamesortOrder只能是ASC或DESC。可以通过一个预定义的Set来校验。Like查询的正确姿势。使用#{}进行like查询时需要在参数值两侧添加%通配符有几种方式在Java代码中拼接String name % userInput %;然后传入#{name}。简单直接。在XML中使用CONCAT函数AND username LIKE CONCAT(%, #{name}, %)。这是更推荐的方式逻辑清晰且数据库兼容性好。使用bind标签MyBatis 3.2.3select idfindUsers bind namepattern value% username % / SELECT * FROM user WHERE username LIKE #{pattern} /select绝对禁止AND username LIKE %${name}%这是典型的注入漏洞。定期进行安全扫描与代码审计。将奇安信等安全扫描工具集成到CI/CD流程中对每次提交的代码进行自动扫描。同时在代码评审环节将SQL语句的安全性作为必审项。5.2 常见问题排查与调试技巧即使再小心问题也难免出现。这里有一些快速定位问题的思路。问题SQL执行报错提示参数未找到如There is no getter for property named XXX in class java.lang.String排查检查接口方法参数和XML中#{}或${}内的名称是否匹配。如果接口方法只有一个基本类型参数如String name在XML中应该使用_parameter或Param注解指定名字。最佳实践是即使单个参数也使用Param注解。问题查询结果映射失败部分字段为null排查检查ResultMap中property和column的对应关系是否正确尤其是大小写和下划线转驼峰的情况。MyBatis默认开启mapUnderscoreToCamelCase配置可以将user_name自动映射到userName。检查数据库查询返回的列名是否与column指定的一致。有时SQL中使用别名会导致不一致。使用日志功能将最终执行的SQL语句和参数打印出来直接在数据库客户端执行看结果是否正确。问题动态SQL拼接结果不符合预期排查开启MyBatis的完整日志设置日志级别为DEBUG查看控制台输出的“Preparing:”和“Parameters:”语句。Preparing:显示的是预编译前的SQL${}已被替换#{}显示为?Parameters:显示的是传入的参数值。对比这个SQL和你预期的SQL就能发现动态条件拼接的逻辑错误。问题N1查询问题导致性能低下现象查询一个列表1次查询列表中的每个对象又触发一次关联查询N次查询总查询次数为1N。解决方案使用嵌套结果映射collection/associationJOIN通过单条复杂的SQL一次性将主对象和关联对象的数据全部查询出来在ResultMap中完成映射。这是最常用的优化手段。使用嵌套查询collection/associationselect属性在ResultMap中通过select属性指定另一个查询的id。这种方式可能会产生N1问题务必设置fetchTypelazy延迟加载只有在真正访问关联属性时才执行查询。同时可以通过全局配置lazyLoadingEnabled和aggressiveLazyLoading来优化加载行为。问题批量操作性能差或报错排查批量插入检查是否因列表过大导致SQL超长。需要在Service层进行分批每批几百到几千条执行一次。批量更新考虑使用foreach拼接成UPDATE table SET ... WHERE id IN (...)的语句或者使用CASE WHEN语句进行批量更新。对于超大批量建议使用JDBC批处理或MyBatis的ExecutorType.BATCH模式。5.3 性能优化要点清单SQL本身是根本在XML中写的SQL首先要保证在数据库客户端执行是高效的。合理使用索引避免全表扫描优化JOIN和子查询。合理使用延迟加载对于不是立即需要的关联数据一定要设置fetchTypelazy或全局启用延迟加载。控制返回数据量避免使用SELECT *在sql片段中明确列出需要的字段。在动态查询中如果前端只需要部分字段可以考虑定义不同的ResultMap或使用sql片段动态组装字段列表。警惕大结果集的分页对于LIMIT 1000000, 20这种深分页考虑改用“基于ID查询”的方式。缓存策略选择根据数据特性和访问模式谨慎配置一级、二级缓存。对于写多读少的数据关闭缓存。监控与日志在生产环境通过监控系统观察慢SQL。在开发测试环境开启MyBatis的SQL日志便于分析和优化。最后关于“MyBatis使用的什么代理”这个面试题简单提一下MyBatis通过JDK动态代理如果接口有实现类或CGLIB如果没有为Mapper接口生成代理对象。当调用接口方法时代理对象会根据方法名和命名空间找到对应的MappedStatement即XML中配置的SQL然后交给Executor去执行。理解这个流程有助于你在更深层次上排查问题比如为什么某个方法没有找到对应的SQL语句。
1. 项目概述为什么我们需要一份MyBatis XML的“生存手册”干了这么多年Java后端MyBatis绝对是绕不开的老朋友。尤其是它的XML映射文件说它是项目里的“定海神针”一点不为过。但就是这个看似简单的.xml文件坑起人来毫不手软。我见过太多团队项目初期为了赶进度SQL写得飞起各种${}直接拼接参数动态SQL逻辑嵌套得比俄罗斯套娃还复杂。等到项目要上线做安全扫描奇安信这类工具一跑满屏的“SQL注入漏洞”告警直接让人头皮发麻。或者是在高并发场景下一个没写好的动态条件查询因为参数为空导致全表扫描性能瞬间雪崩。更别提那些因为resultMap配置不当导致的数据映射错误或是模糊查询时因为参数处理不当引发的诡异问题。所以我决定整理这份“常用总结”。它不是什么官方文档的复刻而是我这些年踩过坑、填过坑后沉淀下来的实战经验合集。目的很明确当你接手一个老项目或者自己写代码时感觉心里没底打开这份总结能快速找到那个“标准答案”和“避坑指南”。我会围绕最核心、最常用、也最容易出错的点展开比如动态SQL的#{}和${}到底怎么选才能既安全又灵活resultMap如何优雅地处理复杂关联以及如何写出既高效又安全的CRUD语句。这份总结是“持续更新”的因为技术和最佳实践也在变我会把遇到的新问题、新解法不断补充进来。2. 核心基石深入理解MyBatis XML的配置与映射在开始写复杂的动态SQL之前我们必须把地基打牢。MyBatis XML的核心配置元素每一个都有其明确的职责和需要注意的细节理解它们是写出稳健代码的第一步。2.1 映射文件的结构与核心元素一个标准的MyBatis Mapper XML文件通常遵循以下结构。这不仅仅是格式更是一种逻辑组织。?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就是通过这个namespace将XML中的SQL语句与Java接口中的方法绑定起来的。如果这里写错运行时就会报“BindingException”告诉你找不到对应的语句。接下来文件体内主要包含以下几类元素select、insert、update、delete 对应CRUD操作。每个元素都有一个唯一的id属性这个id就是接口中对应的方法名。sql 用于定义可重用的SQL片段。这是提升XML可维护性的关键工具避免重复代码。resultMap 定义数据库结果集到Java对象属性的复杂映射规则。当字段名和属性名不一致或者存在一对一、一对多关联时必须使用它。parameterMap 老式参数映射现在基本已被Param注解和直接在SQL中使用#{}的方式取代不推荐使用。2.2#{}与${}的天壤之别安全与灵活性的抉择这是MyBatis面试必问也是实际开发中最容易埋雷的地方。两者的区别本质上就是“预编译”和“字符串拼接”的区别。#{}预编译占位符MyBatis在处理#{}时会将其替换为JDBC的?占位符然后通过PreparedStatement来赋值。这个过程是预编译的。优点绝对防止SQL注入因为参数值是在预编译后才传入的不会被解释为SQL指令的一部分。这是应对奇安信等安全扫描的最根本手段。自动类型处理MyBatis会根据参数对象的类型自动进行java.util.Date到java.sql.Date等转换。通常不需要处理引号对于字符串参数MyBatis会自动加上引号。示例SELECT * FROM user WHERE name #{name}会被编译为SELECT * FROM user WHERE name ?然后安全地传入参数值。${}字符串替换MyBatis在处理${}时会直接将其中的内容作为字符串拼接到SQL语句中。风险SQL注入漏洞如果${}中的内容是用户可控的输入如搜索关键词恶意用户输入 OR 11就会导致严重的注入攻击。这正是安全扫描工具会报警的地方。需要手动处理引号和类型拼接字符串需要你自己考虑是否加单引号数字类型则不能加。适用场景非常有限且需谨慎动态表名或列名例如根据参数动态选择查询哪张表。SELECT * FROM ${tableName}。必须确保tableName的值来自可信的枚举或配置绝对不能让用户输入。ORDER BY子句动态排序字段如ORDER BY ${orderByField} ${orderByType}。同样需要对参数值进行严格的白名单校验。核心原则默认永远使用#{}。仅在不得不使用${}的场景下且对参数值进行严格的、可信的校验和过滤后才考虑使用。在99%的WHERE条件参数传递中都应该用#{}。2.3 ResultMap对象映射的艺术当数据库查询返回的结果无法通过简单的自动映射字段名属性名完成时resultMap就是你的利器。基础字段映射resultMap idBaseResultMap typecom.example.model.User id propertyid columnuser_id/ !-- 主键字段建议用id -- result propertyusername columnuser_name/ result propertyemail columnemail_address/ !-- 如果属性名和列名相同可以省略但显式声明更清晰 -- /resultMapid标签用于指定主键字段有助于提高性能如缓存标识。property对应Java对象属性column对应数据库列名。处理关联关系一对一一对多 这是ResultMap真正强大的地方。假设一个User拥有多个Order。resultMap idUserWithOrdersResultMap typeUser extendsBaseResultMap !-- 一对多关联一个用户有多个订单 -- collection propertyorderList ofTypeOrder fetchTypelazy id propertyorderId columnorder_id/ result propertyorderNo columnorder_no/ result propertyamount columnamount/ !-- 订单对象中可能还有关联可以继续嵌套 -- /collection /resultMapcollection用于映射一对多关系。property是User类中的ListOrder orderList属性名ofType是集合中元素的类型。fetchTypelazy表示延迟加载这是一个非常重要的性能优化点。只有在代码中真正访问user.getOrderList()时MyBatis才会执行查询订单的SQL。默认情况下MyBatis的关联是延迟加载的但通过fetchType可以显式控制。高级技巧association与复杂联合查询对于一对一关联如一个订单对应一个发货地址使用association。resultMap idOrderDetailResultMap typeOrder association propertydeliveryAddress javaTypeAddress result propertycity columnaddr_city/ result propertystreet columnaddr_street/ /association /resultMap对于复杂的、需要连接多个表的查询可以在SQL中使用JOIN然后在ResultMap中通过association或collection的column和columnPrefix属性精细地映射来自不同表的、可能有列名重复的结果集。这比发起多次查询N1问题通常性能更高。3. 动态SQL构建灵活且安全的查询体系动态SQL是MyBatis XML的灵魂它允许我们根据运行时条件来动态拼接SQL语句避免编写大量重复且难以维护的if-elseJava代码。但能力越大责任越大动态SQL也是最容易写出性能问题和安全漏洞的地方。3.1 核心标签详解与应用场景if条件判断最常用的标签用于在满足条件时包含某段SQL。select idfindUsers resultMapBaseResultMap SELECT * FROM user WHERE 11 !-- 避免WHERE后面直接跟AND的技巧但并非最优 -- if testusername ! null and username ! AND username LIKE CONCAT(%, #{username}, %) /if if testemail ! null AND email #{email} /if /selecttest属性内是OGNL表达式可以直接使用参数对象的属性进行判断。注意字符串空值判断username ! 。where、set、trim智能处理前缀where智能处理WHERE子句。它会自动删除开头多余的AND或OR并且只有在子元素有返回内容时才会插入WHERE关键字。这是处理动态条件的最佳实践可以抛弃11这种取巧但影响可读性和性能的写法。select idfindUsers resultMapBaseResultMap SELECT * FROM user where if testusername ! null AND username #{username} /if if testemail ! null AND email #{email} /if /where /selectset用于UPDATE语句智能处理SET子句自动删除末尾多余的逗号。update idupdateUserSelective UPDATE user set if testusername ! nullusername #{username},/if if testemail ! nullemail #{email},/if if teststatus ! nullstatus #{status},/if /set WHERE id #{id} /updatetrim更通用的标签可以自定义要添加的前缀、后缀以及要删除的前缀、后缀。where和set都可以用trim来实现它提供了最高的灵活性。!-- 等价于 where -- trim prefixWHERE prefixOverridesAND |OR ... /trim !-- 等价于 set -- trim prefixSET suffixOverrides, ... /trimchoose,when,otherwise多路选择类似于Java中的switch-case用于实现互斥的条件选择。select idfindActiveUsers resultMapBaseResultMap SELECT * FROM user where choose when teststatus ACTIVE AND status ACTIVE AND last_login_time #{recentDate} /when when teststatus INACTIVE AND status INACTIVE /when otherwise AND status IS NOT NULL !-- 默认条件 -- /otherwise /choose /where /selectforeach遍历集合这是处理IN查询和批量操作的利器。常见场景根据一组ID查询用户或批量插入数据。!-- 查询ID在指定列表中的用户 -- select idfindUsersByIds resultMapBaseResultMap SELECT * FROM user WHERE id IN foreach collectionidList itemid indexindex open( separator, close) #{id} /foreach /selectcollection: 传入的参数集合属性名。如果接口方法参数是List通常写list如果用了Param(ids)则写ids。item: 遍历时的每个元素的变量名。open/close: 循环体开始和结束时添加的字符串。separator: 元素之间的分隔符。批量插入示例insert idbatchInsertUsers INSERT INTO user (username, email) VALUES foreach collectionuserList itemuser separator, (#{user.username}, #{user.email}) /foreach /insert注意MySQL对单条SQL的长度有限制max_allowed_packet。当userList非常大时直接拼接成一条巨型SQL可能导致报错。在实际生产中需要对大列表进行分批次处理例如每1000条执行一次插入。3.2 参数传递与OGNL表达式技巧动态SQL的test属性中使用的OGNL表达式非常强大。判断集合是否为空if testlist ! null and list.size() 0或更简洁的if testlist ! null and !list.isEmpty()。这是处理foreach前必须做的防御性判断否则可能运行时报错。字符串判断除了判空还可以判断是否包含特定字符串如if testname ! null and name.contains(admin)。数值比较if testage ! null and age gt 18(gt表示大于)。调用静态方法可以通过全限定类名方法名调用静态方法但需谨慎使用因为会降低SQL的可移植性。参数传递的几种方式单个简单类型参数在SQL中可以直接使用#{参数名}但为了清晰建议使用Param注解。多个参数必须使用Param(name)注解然后在XML中通过#{name}引用。JavaBean对象直接使用属性名如#{username}。Map通过key来引用如#{mapKey}。传递ListString参数这是热词中提到的一个具体问题。在接口中定义为ListString types在XML的foreach中collection直接写typesitem写type即可。如果参数是Map中的一个List则需要写collectionmapKey。4. 高级特性与性能优化实战掌握了基础我们来看看如何让MyBatis XML用得更高效、更强大。这部分内容往往决定了应用在高负载下的表现。4.1 缓存机制深度解析MyBatis提供了一级缓存和二级缓存。理解它们是进行性能调优的基础。一级缓存SqlSession级别范围默认开启在同一个SqlSession通常对应一次数据库会话/事务内有效。行为执行查询后结果会被缓存。在同一个SqlSession中再次执行完全相同的SQL和参数时会直接返回缓存对象而不会再次访问数据库。失效时机执行了INSERT、UPDATE、DELETE操作任何写操作。手动调用sqlSession.clearCache()。执行了其他会导致缓存失效的查询如查询不同的命名空间。SqlSession被关闭。注意事项一级缓存可能导致“脏读”。例如在同一个SqlSession中你先查询了一个用户然后在另一个方法中修改了该用户但未提交此时再查询得到的仍是缓存中的旧数据。在涉及多个操作的复杂业务中需要留意。二级缓存Mapper级别/命名空间级别范围需要手动在XML中配置开启作用于整个Mapper命名空间可以被多个SqlSession共享。配置mapper namespacecom.example.dao.UserMapper cache evictionLRU flushInterval60000 size512 readOnlytrue/ !-- 其他语句 -- /mappereviction缓存回收策略如LRU最近最少使用、FIFO先进先出。flushInterval缓存刷新间隔毫秒到期后缓存清空。size最多可以存储的对象数。readOnly是否为只读。只读缓存性能更高但返回的是缓存对象的引用修改它们会影响缓存。非只读false会返回序列化后的副本更安全但性能稍差。工作机制当一个SqlSession关闭或提交时其查询结果才会被存入二级缓存。另一个SqlSession查询时如果命中缓存则直接返回。使用陷阱与建议实体类必须实现Serializable接口因为二级缓存可能将数据存储到磁盘或跨进程。查询语句的useCache和flushCache属性可以细粒度控制单个语句是否使用缓存(useCachetrue)或执行后是否刷新缓存(flushCachetrue)。对于更新频繁的数据可以考虑关闭其缓存。缓存共享问题如果多个Mapper操作同一张表且都开启了二级缓存需要小心缓存数据不一致。可以通过cache-ref来让多个Mapper共享同一个缓存实例但这增加了复杂度。分布式环境默认的基于内存的二级缓存在分布式环境下无效。生产环境通常会集成Redis等分布式缓存作为二级缓存实现。个人心得对于读远多于写、且数据实时性要求不高的配置表、字典表开启二级缓存收益明显。对于核心业务表尤其是写操作频繁的我通常不建议开启二级缓存维护缓存一致性的成本可能高于其带来的性能收益。一级缓存通常够用且更可控。4.2 分页查询的演进与最佳实践分页是高频操作其实现方式直接影响性能和用户体验。1. 原始Limit分页适合简单场景select idfindUsersByPage resultMapBaseResultMap SELECT * FROM user ORDER BY create_time DESC LIMIT #{offset}, #{pageSize} /select简单直接但在数据量极大offset非常大时MySQL需要扫描大量数据然后丢弃性能很差。2. 基于“上一页最大ID”的分页性能最优这是一种“seek method”利用索引的有序性避免OFFSET的大规模扫描。select idfindUsersAfterId resultMapBaseResultMap SELECT * FROM user WHERE id #{lastMaxId} !-- 假设id是自增主键且有序 -- ORDER BY id ASC LIMIT #{pageSize} /select这种方式性能极佳但限制是只能“下一页”查询不支持直接跳到任意页码。适合瀑布流、无限滚动加载的场景。3. 使用MyBatis分页插件如PageHelper这是国内最流行的方案。通过在查询方法前调用PageHelper.startPage(pageNum, pageSize)插件会自动拦截后续的查询SQL为其加上分页语句如LIMIT并同时执行一个COUNT(*)查询获取总记录数封装到PageInfo对象中。优点使用极其方便功能强大支持多种数据库提供PageInfo包含总页数、当前页等丰富信息。注意事项确保PageHelper.startPage()紧跟要分页的查询语句中间不要有其它查询否则会被错误拦截。分页语句是插件动态添加的要确保原SQL是支持分页的简单查询没有UNION、存储过程等复杂结构。对于超大数据量的COUNT(*)操作可能很慢可以考虑用其他方式估算总数或者使用“不查询总数”的模式。4. 数据库原生分页如Oracle的ROWNUMSQL Server的OFFSET FETCH原理类似写法因数据库而异。MyBatis分页插件通常能自动识别数据库类型并生成正确的分页SQL。4.3sql片段与include提升可维护性当多个查询语句中有重复的SQL片段时如复杂的字段列表、通用的查询条件使用sql定义片段再用include引用可以极大提升可维护性。!-- 定义可重用的列名片段 -- sql idBase_Column_List id, username, email, create_time, status /sql !-- 定义可重用的查询条件片段 -- sql idWhere_Active where status ACTIVE if testdepartmentId ! null AND department_id #{departmentId} /if /where /sql !-- 在查询中引用 -- select idselectActiveUsers resultMapBaseResultMap SELECT include refidBase_Column_List/ FROM user include refidWhere_Active/ ORDER BY create_time DESC /select这样做的好处是当表结构变更如字段名修改或公共查询逻辑变化时只需修改一处sql定义即可。5. 安全编码、疑难排查与性能调优这一章是我们经验的结晶很多都是线上真实踩过的坑。掌握了这些你写出的MyBatis XML才真正具备生产级可靠性。5.1 严防SQL注入从编码到扫描的防御体系安全无小事尤其是在奇安信等安全扫描成为标配的今天。根本大法坚持使用#{}。再次强调所有来自用户输入、外部接口、甚至内部非绝对可信源的参数在拼接进WHERE、SET、VALUES、HAVING等子句时必须使用#{}。这是第一道也是最重要的防线。审慎使用${}并施加白名单校验。如果业务上确实需要动态表名、列名或排序字段必须对${}中的变量值进行严格校验。!-- 危险的写法 -- ORDER BY ${sortField} ${sortOrder} !-- 相对安全的写法需在Java代码或XML中校验 --对应的Java代码或XML中的if测试应确保sortField只能是允许的字段名枚举如create_time,usernamesortOrder只能是ASC或DESC。可以通过一个预定义的Set来校验。Like查询的正确姿势。使用#{}进行like查询时需要在参数值两侧添加%通配符有几种方式在Java代码中拼接String name % userInput %;然后传入#{name}。简单直接。在XML中使用CONCAT函数AND username LIKE CONCAT(%, #{name}, %)。这是更推荐的方式逻辑清晰且数据库兼容性好。使用bind标签MyBatis 3.2.3select idfindUsers bind namepattern value% username % / SELECT * FROM user WHERE username LIKE #{pattern} /select绝对禁止AND username LIKE %${name}%这是典型的注入漏洞。定期进行安全扫描与代码审计。将奇安信等安全扫描工具集成到CI/CD流程中对每次提交的代码进行自动扫描。同时在代码评审环节将SQL语句的安全性作为必审项。5.2 常见问题排查与调试技巧即使再小心问题也难免出现。这里有一些快速定位问题的思路。问题SQL执行报错提示参数未找到如There is no getter for property named XXX in class java.lang.String排查检查接口方法参数和XML中#{}或${}内的名称是否匹配。如果接口方法只有一个基本类型参数如String name在XML中应该使用_parameter或Param注解指定名字。最佳实践是即使单个参数也使用Param注解。问题查询结果映射失败部分字段为null排查检查ResultMap中property和column的对应关系是否正确尤其是大小写和下划线转驼峰的情况。MyBatis默认开启mapUnderscoreToCamelCase配置可以将user_name自动映射到userName。检查数据库查询返回的列名是否与column指定的一致。有时SQL中使用别名会导致不一致。使用日志功能将最终执行的SQL语句和参数打印出来直接在数据库客户端执行看结果是否正确。问题动态SQL拼接结果不符合预期排查开启MyBatis的完整日志设置日志级别为DEBUG查看控制台输出的“Preparing:”和“Parameters:”语句。Preparing:显示的是预编译前的SQL${}已被替换#{}显示为?Parameters:显示的是传入的参数值。对比这个SQL和你预期的SQL就能发现动态条件拼接的逻辑错误。问题N1查询问题导致性能低下现象查询一个列表1次查询列表中的每个对象又触发一次关联查询N次查询总查询次数为1N。解决方案使用嵌套结果映射collection/associationJOIN通过单条复杂的SQL一次性将主对象和关联对象的数据全部查询出来在ResultMap中完成映射。这是最常用的优化手段。使用嵌套查询collection/associationselect属性在ResultMap中通过select属性指定另一个查询的id。这种方式可能会产生N1问题务必设置fetchTypelazy延迟加载只有在真正访问关联属性时才执行查询。同时可以通过全局配置lazyLoadingEnabled和aggressiveLazyLoading来优化加载行为。问题批量操作性能差或报错排查批量插入检查是否因列表过大导致SQL超长。需要在Service层进行分批每批几百到几千条执行一次。批量更新考虑使用foreach拼接成UPDATE table SET ... WHERE id IN (...)的语句或者使用CASE WHEN语句进行批量更新。对于超大批量建议使用JDBC批处理或MyBatis的ExecutorType.BATCH模式。5.3 性能优化要点清单SQL本身是根本在XML中写的SQL首先要保证在数据库客户端执行是高效的。合理使用索引避免全表扫描优化JOIN和子查询。合理使用延迟加载对于不是立即需要的关联数据一定要设置fetchTypelazy或全局启用延迟加载。控制返回数据量避免使用SELECT *在sql片段中明确列出需要的字段。在动态查询中如果前端只需要部分字段可以考虑定义不同的ResultMap或使用sql片段动态组装字段列表。警惕大结果集的分页对于LIMIT 1000000, 20这种深分页考虑改用“基于ID查询”的方式。缓存策略选择根据数据特性和访问模式谨慎配置一级、二级缓存。对于写多读少的数据关闭缓存。监控与日志在生产环境通过监控系统观察慢SQL。在开发测试环境开启MyBatis的SQL日志便于分析和优化。最后关于“MyBatis使用的什么代理”这个面试题简单提一下MyBatis通过JDK动态代理如果接口有实现类或CGLIB如果没有为Mapper接口生成代理对象。当调用接口方法时代理对象会根据方法名和命名空间找到对应的MappedStatement即XML中配置的SQL然后交给Executor去执行。理解这个流程有助于你在更深层次上排查问题比如为什么某个方法没有找到对应的SQL语句。
