Mybatis ＜foreach＞在＜when＞中失效

最新推荐文章于 2023-10-06 22:39:48 发布

原创最新推荐文章于 2023-10-06 22:39:48 发布 · 221 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#mybatis

在Mybatis的XML映射文件中，遇到使用<foreach>标签时，在<when>内无法正常识别集合list，导致解析错误。文章指出在这种情况下，建议改用<if>标签进行动态条件判断，以实现相同的功能。这是一个关于MybatisXML配置和动态SQL常见的技术问题。

Mybatis <foreach>在<when>中无法使用，会找不到集合list，只能使用<if>动态解析

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

brianhang

关注关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

MyBatis动态SQL中if、where、trim、choose、when、otherwise、foreach标签及sql标签范例

m0_61961937的博客

09-26

3573

MyBatis动态SQL中if、where、trim、choose、when、otherwise、foreach标签及sql标签范例

mybatis中foreach使用

冬阳

04-25

3665

mybatis使用foreach标签

参与评论您还未登录，请先登录后发表或查看评论

mybatis复杂mapper之foreach、if、choose、when动态sql

Be_insighted的博客

11-12

6539

foreach五大标签： item 　　表示集合中每一个元素进行迭代时的别名，随便起的变量名； index 也就是索引，用于表示在迭代过程中，每次迭代到的位置； open　　表示该语句以什么开始，常用“(”； separator 表示在每次进行迭代之间以什么符号作为分隔符，常用“,”； close　　表示以什么结束，常用“)”； collection 该属性是必须指定的，但是在不同情况下，该属性的值是不一样的，默认使用list 对于collec.........

mybatis ＜choose＞＜when＞的判断条件不生效

gzg_123的博客

06-24

4433

mybatis 的判断条件不生效

【Mybatis中if、when标签判断不生效】

qq_33402651的博客

08-12

3807

mybatis映射文件中if、when判断失效。

mybatis使用拦截器后，foreach失效

熊浪的博客

05-10

2992

使用mybatis拦截器需要小心，低版本是foreach会失效，这是因为我们新建立的boundSql对象的metaParameters属性值没有复制，不设置originalObject为0，foreach遍历就会为空。所以我们需要给新的boundSql添加metaParameters属性值，通过反射获取老的boundSql的metaParameters属性值，设置到新...

mybatis--foreach，choose 小结

believer123的专栏

06-23

2342

写博客个人不喜欢写那种长篇大论，富有文采与哲学的文章，搞开发的就喜欢直击重点，只记录重要的信息就好了，以后查看的时候也非常方便！ mybatis 中在if语句或when中如果判断一个字段是否和1相同，则需使用: 而不是，when中的条件也一样！在使用foreach中，迭代集合或俗数组对象的时候，如果传入的参数就是数组或集合对象则在使用时得注意： <foreach i

MyBatis-动态SQL的if、choose、when、otherwise、trim、where、set、foreach使用

热门推荐

记事本

05-30

7万+

动态SQL是MyBatis最强大的特性之一。用于实现动态SQL的主要元素如下： 1、if 2、choose、when、otherwise 3、trim、where、set 4、foreach代码示例：1、ifEmpMapper.xml配置<select id="getEmpByIf" resultType="Emp" parameterType="Emp"> select * fro

Mybatis3.1.1 if 或者 when判断条件不通过的问题

jiang_zf的博客

05-19

3100

Mybatis3.1.1中 if 或者 when如果按照下面的写法是不会通过的。错误写法：<when test="reqType != null and reqType == '0'"><if test="reqType != null and reqType == '0'">因为里面的单引号包裹的字符串（例子中是'0'）解析时候被去掉单引号认为是数值。正确写法：<w...

【Mybatis】动态SQL的实现，＜where＞、＜if＞、＜choose＞-＜when＞、＜set＞、＜foreach＞

✈ 正在努力の寒江（StudiousTiger) ✌ 呐 ✈

06-22

593

文章目录一、介绍二、if三、where四、choose五、set六、foreach 一、介绍动态 SQL 是 MyBatis 的强大特性之一。如果你使用过 JDBC 或其它类似的框架，你应该能理解根据不同条件拼接 SQL 语句有多痛苦，例如拼接时要确保不能忘记添加必要的空格，还要注意去掉列表最后一个列名的逗号。利用动态 SQL，可以彻底摆脱这种痛苦。使用动态 SQL 并非一件易事，但借助可用于任何 SQL 映射语句中的强大的动态 SQL 语言，MyBatis 显著地提升了这一特性的易用性。如

015MyBatis中foreach用法

java1592724884的博客

08-04

931

foreach元素主要用于对一个集合（List、Set、Map、数组）进行遍历 foreach支持如下属性 collection：指定要遍历的集合【也就是传过来的参数，但是不能用param和arg0，要么注解指定参数名。要么用默认的参数名list/set/map/array，当然这个时候的参数只有一个】 index: 在map中代表key，其他集合可以不用指定 item：在map中代表value，其他集合代表当前遍历的元素，充当变量 open：循环开始处放置的字符串 close：循环结束出放置的字符串 s

Mybatis的动态Sql（if 、trim 、where 、set 、choose（when、otherwise）、 foreach、查询分页功能）详解示例

qq_48033003的博客

07-18

540

Mybatis的动态Sql（if 、trim 、where 、set 、choose（when、otherwise）、 foreach）详解示例用于实现动态Sql的元素主要有 if trim where set choose（when、otherwise） foreach if 标签详解需求说明实现对用户表数据的查询要求通过姓名模糊查询以及性别的联合或者单一查询解读：就是说可以通过姓名模糊单条件查询，也可以通过性别单条件查询，也可以双条件查询问题如何实现传入单个条件，查询单个

jsp、jstl的＜c:if＞、＜c:when＞标签不起效果/作用

Arvin

10-16

4148

如果你有在使用jstl，你会发现下面的代码不起作用，输出结果为 “无”：这个jstl语句输出结果永远也为“无” 这个bug我找了很久、很久终于发现test语句里不能包含多余的空格，本来我是想让它好看一点的，搞了一个空格，然后就这样导致结果不正确。正确的做法，如下：去掉test中的所有空格 ...

mybatis（19）——choose标签，when标签和otherwise标签

木子旭的博客

04-12

1450

代码 <select id="getStudents" resultType="student" parameterType="map"> select * from mybatis_test.student <where> <choose> <when test="id != null"> id = #{id} </when>

MyBatis Mapper常用动态SQL之foreach 、if、choose、where、when

SSY_1992的博客

04-20

4980

if>判断语句，用于单条件分支条件判断使用

mapper.xml中foreach里涉及when和then的含义

weixin_37841024的博客

10-06

491

每个 `when` 子句表示当 `deptId` 匹配时，将 `ancestors` 值更新到 `sys_dept` 表的 `ancestors` 字段。它遍历 `depts` 列表中的每个元素，并生成 `dept_id` 的 `IN` 条件，以将更新限制为指定的 `deptId` 值。通过以上配置，可以根据传入的 `depts` 列表中的元素动态生成更新语句，将指定的 `deptId` 的 `ancestors` 值更新到 `sys_dept` 表中，并通过 `deptId` 的条件限制更新的范围。

Mybatis Mapper的动态SQL语句问题、if-else、choose、when、foreach

七七的博客

11-24

1万+

文章目录Mybatis Mapper的动态SQL语句问题一、if二、choose、when、otherwise三、where四、trim 元素来定制 where 元素的功能五、set 动态地在行首插入 SET 关键字六、foreach七、script八、bind应用举例1、Mybatis Mapper中字符串if判断2、MyBatis Mapper中的if-else判断内容来自mybatis官网，此处做学习记录，了解更多：Mybatis官网 Mybatis Mapper的动态SQL语句问题一、if 使用

mybatis动态sql的使用(以及特殊查询、内置参数等)

enthan809882的博客

03-22

625

mybatis动态sql的使用(以及特殊查询)

mybatis xml 解析 <sql > <where> <if> <foreach>这些标签查询sqlserver很慢，但是将打印出的sql在数据库中直接执行很快，什么原因引起的，如何解决，在接口中，因为有很多这样的查询条件，如何解决

最新发布

11-13

<think> 我们面对的问题是：在MyBatis中使用动态SQL标签（如<sql>, <where>, <if>, <foreach>）构建的查询在SQL Server上执行很慢，但将打印出的SQL直接执行却很快。同时，接口中有很多查询条件，需要解决性能问题。分析原因： 1. **参数嗅探问题（Parameter Sniffing）**：SQL Server在第一次执行存储过程或参数化查询时会生成一个执行计划，该计划基于第一次传入的参数值进行优化。如果后续传入的参数值差异很大，可能导致使用不合适的执行计划，从而性能下降。在MyBatis中，虽然我们使用的是动态SQL，但最终生成的SQL语句是参数化的（使用?占位符），所以也存在参数嗅探问题。 2. **动态SQL拼接导致的执行计划不准确**：由于动态SQL会根据条件不同生成不同的SQL语句，每次生成的SQL语句结构可能不同，这导致SQL Server无法重用执行计划，或者每次都要重新编译，增加了开销。 3. **<foreach>标签导致的性能问题**：当使用<foreach>进行in查询时，如果in列表中的元素数量变化很大，也会导致执行计划不准确。例如，有时in列表有10个元素，有时有1000个元素，但SQL Server可能只缓存了一个执行计划，而这个计划对于大量元素并不高效。 4. **统计信息不准确**：SQL Server根据统计信息来生成执行计划，如果统计信息过时，可能导致执行计划不优。解决办法： 1. **解决参数嗅探问题**： - 使用`OPTION(RECOMPILE)`：在SQL语句末尾添加`OPTION(RECOMPILE)`，让SQL Server每次执行时都重新编译，生成适合当前参数值的执行计划。但注意，这会增加CPU开销。 - 使用`OPTIMIZE FOR UNKNOWN`：告诉SQL Server使用一个通用的执行计划，而不是基于特定参数值。 - 使用本地变量：将参数赋值给本地变量，然后在查询中使用本地变量。这样SQL Server在生成执行计划时就不会使用参数的值，而是基于本地变量的未知值（通常使用密度向量）来生成计划。 2. **优化动态SQL**： - 避免过于复杂的动态SQL，尽量保持SQL结构稳定。例如，即使某个条件不满足，也可以使用一个恒真条件（如1=1）来保持结构一致。 - 使用`<where>`标签可以避免多余的`WHERE`关键字，但注意，如果条件都为空，则整个WHERE子句不会生成，这可能导致全表扫描。因此，可以考虑在`<where>`标签内添加一个恒真条件（如1=1）来确保WHERE子句存在，然后使用`<if>`添加条件。 3. **优化<foreach>标签**： - 对于in列表元素数量变化大的情况，考虑使用临时表或表变量，将参数值插入临时表，然后使用JOIN代替IN查询。这样执行计划会更稳定。 - 如果元素数量不是特别大，可以使用`OPTION(RECOMPILE)`来针对每次不同的元素数量重新生成计划。 4. **更新统计信息**： - 确保表的统计信息是最新的，可以通过`UPDATE STATISTICS`命令手动更新。 5. **使用强制重编译（Recompile）提示**： - 在MyBatis的SQL语句末尾添加`OPTION (RECOMPILE)`，例如： ```xml <select id="selectUsers" resultType="User"> SELECT * FROM users <where>  </where> OPTION (RECOMPILE) </select> ``` 但注意，这会让每次执行都重新编译，适用于执行频率不高但每次参数差异大的情况。 6. **使用执行计划指导优化**： - 使用SQL Server的执行计划分析工具，查看慢的时候的执行计划和直接执行时的执行计划有何不同，从而针对性优化。对于接口中有很多查询条件的问题，除了上述性能优化外，还可以考虑： - **分页查询**：如果返回数据量很大，使用分页（如MyBatis的PageHelper）减少单次返回的数据量。 - **减少查询字段**：只查询必要的字段，避免使用`SELECT *`。 - **建立合适的索引**：根据查询条件建立索引，特别是经常作为条件的字段。下面是一个使用本地变量解决参数嗅探的示例（在MyBatis中）： ```xml <select id="selectUsers" resultType="User"> DECLARE @local_param1 INT = #{param1}; DECLARE @local_param2 VARCHAR(20) = #{param2}; SELECT * FROM users <where> <if test="param1 != null"> AND column1 = @local_param1 </if> <if test="param2 != null"> AND column2 = @local_param2 </if> </where> </select> ``` 注意：这种方法在MyBatis中需要将整个声明和查询写在一个语句中，且需要确保SQL Server允许在单个语句中声明变量。但是，MyBatis默认情况下是不允许在一个SQL语句中执行多个语句的（除非修改配置允许）。因此，这种方法可能不适用。因此，更推荐使用`OPTION(RECOMPILE)`，因为它不会改变SQL语句结构，且对性能的影响在参数变化大时是正面的。结论：针对参数嗅探问题，在MyBatis的SQL语句末尾添加`OPTION (RECOMPILE)`是最直接的解决办法。同时，应检查并优化索引，更新统计信息。如果使用`OPTION (RECOMPILE)`后性能提升，但CPU开销增加，可以考虑仅在参数变化大的查询中使用。另外，对于<foreach>标签，如果in列表元素数量变化大，可以尝试使用临时表方法。示例：使用临时表代替<foreach>的in查询步骤： 1. 创建一个表变量或临时表，将参数列表插入其中。 2. 使用JOIN代替IN子句。在MyBatis中实现： ```xml <select id="selectUsersByIds" resultType="User"> CREATE TABLE #ids (id INT PRIMARY KEY); INSERT INTO #ids (id) VALUES <foreach collection="ids" item="id" separator=","> (#{id}) </foreach> SELECT u.* FROM users u INNER JOIN #ids ON u.id = #ids.id DROP TABLE #ids </select> ``` 但是，同样需要注意MyBatis默认不支持在一个语句中执行多个SQL（创建表、插入、查询、删除表）。因此，可以将其改写为使用表变量，并在一个语句中完成： ```xml <select id="selectUsersByIds" resultType="User"> DECLARE @ids TABLE (id INT PRIMARY KEY); INSERT INTO @ids (id) VALUES <foreach collection="ids" item="id" separator=","> (#{id}) </foreach> SELECT u.* FROM users u INNER JOIN @ids i ON u.id = i.id </select> ``` 这样，整个查询在一个批处理中执行。但是，请注意，表变量在SQL Server中适用于数据量不大的情况（通常小于1000行），因为表变量没有统计信息，SQL Server会假设表变量只有1行。如果数据量大，可能效果不佳。因此，对于大量数据，可以使用临时表（需要创建统计信息），但需要多个独立的SQL语句，而MyBatis默认不支持。这时，可以考虑使用存储过程。综上，针对原问题，建议的解决方案是： 1. 对于一般动态条件查询，在SQL末尾添加`OPTION (RECOMPILE)`。 2. 对于<foreach>的in查询，如果元素数量变化大，且数量较多，考虑使用临时表（通过存储过程）或者表变量（数量少时）。 3. 更新统计信息，建立合适的索引。最后，关于接口中有很多查询条件的问题，除了性能优化，还可以在代码层面进行重构，将查询条件封装为一个对象，使用动态SQL构建查询，这样保持XML的可读性。同时，注意避免不必要的条件，减少动态SQL的复杂度。示例：使用条件对象和动态SQL ```java public class UserQuery { private Integer id; private String name; private Integer age; // 其他条件... // getter and setter } ``` ```xml <select id="selectUsers" parameterType="UserQuery" resultType="User"> SELECT * FROM users <where> <if test="id != null">AND id = #{id}</if> <if test="name != null">AND name = #{name}</if> <if test="age != null">AND age = #{age}</if>  </where> OPTION (RECOMPILE)  </select> ``` 这样，无论条件多少，都可以灵活构建查询，并且通过`OPTION (RECOMPILE)`避免参数嗅探问题。注意：`OPTION (RECOMPILE)`是SQL Server特有的，如果项目需要多数据库支持，则需要考虑其他方案。如果项目需要支持多数据库，那么可以考虑在配置中根据数据库类型选择是否添加`OPTION (RECOMPILE)`，或者使用其他通用优化方法（如本地变量，但MyBatis中多语句执行需要特殊配置）。因此，总结解决办法如下： - 对于SQL Server，使用`OPTION (RECOMPILE)`解决参数嗅探问题。 - 优化索引和更新统计信息。 - 对于<foreach>标签，如果参数值变化很大，考虑使用临时表或表变量（根据数据量选择）。 - 对于多条件查询，保持动态SQL的简洁，使用条件对象封装查询条件。以上方案需要根据实际场景选择。 </think> ### MyBatis 动态 SQL 查询缓慢问题分析与解决方案 #### 一、直接执行 SQL 快但 MyBatis 执行慢的原因 1. **参数嗅探问题（核心原因）** SQL Server 会对首次执行的 SQL 生成执行计划并缓存。当使用 MyBatis 动态 SQL（特别是 `<if>` 和 `<foreach>`）时： - 每次执行的 SQL 结构可能不同（条件数量/类型变化） - 导致每次生成的执行计划可能不适用新参数 - **现象**：直接执行 SQL 时参数固定，执行计划稳定；MyBatis 动态拼接时参数变化导致计划失效[^1][^2] 2. **执行计划缓存失效** ```xml  <select id="findUsers"> SELECT * FROM users <where> <if test="name != null"> AND name = #{name} </if> <if test="age != null"> AND age > #{age} </if> </where> </select> ``` - 当 `name=null` 时 SQL 变为 `SELECT ... WHERE age > ?` - 当 `age=null` 时 SQL 变为 `SELECT ... WHERE name = ?` - 每次结构变化都触发重新编译执行计划[^2] 3. **`<foreach>` 导致的性能陷阱** ```xml  <select id="getByIds"> SELECT * FROM table WHERE id IN <foreach collection="ids" item="id" open="(" close=")" separator=","> #{id} </foreach> </select> ``` - IN 列表元素数量变化（如 10个 vs 1000个） - 导致索引失效或选择低效扫描计划[^4] 4. **统计信息不准确** - 当表数据量变化大但统计信息未更新时 - SQL Server 可能选择不合适的索引 #### 二、优化解决方案 ##### 1. 解决参数嗅探问题 **方法1：强制重编译（推荐）** ```xml <select id="findUsers"> SELECT * FROM users <where> ... </where> OPTION (RECOMPILE)  </select> ``` - **优点**：确保每次使用最优执行计划 - **代价**：增加约 10-20% CPU 开销，适用于 OLAP 场景 **方法2：使用本地变量** ```sql DECLARE @local_name NVARCHAR(50) = #{name}; DECLARE @local_age INT = #{age}; SELECT * FROM users WHERE (@local_name IS NULL OR name = @local_name) AND (@local_age IS NULL OR age > @local_age) ``` - **原理**：规避参数嗅探，使优化器使用标准密度估计 ##### 2. 优化动态条件结构 **保持 SQL 结构稳定** ```xml <select id="findUsers"> SELECT * FROM users WHERE 1=1  <if test="name != null"> AND name = #{name} </if> <if test="age != null"> AND age > #{age} </if> </select> ``` **使用 `<choose>` 统一分支** ```xml <where> <choose> <when test="type == 'A'"> AND status = 1 </when> <when test="type == 'B'"> AND status = 2 </when> <otherwise> AND status > 0 </otherwise> </choose> </where> ``` ##### 3. 优化 `<foreach>` 查询 **方法1：使用临时表** ```xml <select id="getByIds"> CREATE TABLE #ids (id INT PRIMARY KEY); INSERT INTO #ids VALUES <foreach collection="ids" item="id" separator=",">(#{id})</foreach> SELECT t.* FROM table t JOIN #ids ON t.id = #ids.id </select> ``` **方法2：参数化固定长度** ```java // Java代码补全列表长度 while(ids.size() < 100) { ids.add(-1); // 用无效值补位 } ``` ```xml WHERE id IN <foreach ...>(#{id})</foreach>  ``` ##### 4. 索引与统计优化 - **关键字段建索引**：WHERE/ORDER BY 涉及的字段 - **更新统计信息**：定期执行 `UPDATE STATISTICS table_name` - **强制索引提示（谨慎使用）**： ```sql SELECT * FROM table WITH (INDEX(idx_name)) ``` #### 三、多查询条件接口设计优化 ##### 1. 分层过滤策略 ```java public List<User> queryUsers(QueryParams params) { if (params.isSimpleQuery()) { // 优先走简单条件 return simpleQuery(params); } else { return complexQuery(params); } } ``` ##### 2. 条件组合预处理 ```java // 合并相似条件 public void preProcessParams(QueryParams params) { if (params.getMinAge() != null && params.getMaxAge() != null) { params.setAgeRange(params.getMinAge() + "-" + params.getMaxAge()); params.setMinAge(null); params.setMaxAge(null); } } ``` ##### 3. 动态 SQL 片段复用 ```xml <sql id="baseColumns">id,name,age</sql> <sql id="statusConditions">  <if test="status != null"> AND status = #{status} </if> </sql> <select id="queryByCondition"> SELECT <include refid="baseColumns"/> FROM users <where> <include refid="statusConditions"/>  </where> </select> ``` #### 四、性能验证方案 1. **SQL Profiler 监控** ```sql -- 捕获实际执行的SQL SELECT text, execution_count, total_worker_time FROM sys.dm_exec_query_stats CROSS APPLY sys.dm_exec_sql_text(sql_handle) ``` 2. **执行计划对比** ```sql -- 获取MyBatis执行计划 SET STATISTICS PROFILE ON; EXEC your_procedure @param1=value1, @param2=value2; ``` 3. **强制参数化测试** ```sql ALTER DATABASE current SET PARAMETERIZATION FORCED; ``` > **关键结论**：通过 `OPTION (RECOMPILE)` 解决参数嗅探问题，配合固定 SQL 结构和使用临时表替代 `<foreach>`，可解决 90% 以上的动态 SQL 性能问题[^1][^3]。对超多条件接口采用条件分组和预处理策略可提升维护性。