MyBatis 批量查询在数据量增大后响应时间显著上升，并伴随数据库慢 SQL，如何判断是动态 SQL、参数数量、索引还是对象映射造成？

我会先把问题拆成几个阶段来定位：应用端动态 SQL 生成、参数传输与数据库执行、结果集返回，以及 MyBatis 对象映射，不能只看总响应时间。

先打开 MyBatis 的 SQL 日志或通过拦截器记录以下信息：最终生成的 SQL、参数数量和大小、数据库执行耗时、结果集行数、结果集传输耗时、对象映射耗时。不要只记录带占位符的 SQL，因为动态 SQL 是否展开、是否产生了大量 OR、IN 条件，必须看最终 SQL。

1. 判断是否是动态 SQL 问题

重点检查 <if 、<foreach 、choose 等标签生成的 SQL 是否随着数据量增长而发生结构性变化，例如：

IN 列表变得非常长； 条件没有生效，导致过滤条件缺失； 生成了大量 OR； 出现重复条件、隐式类型转换或不必要的子查询； 批量查询被拼成了多条 SQL，而不是预期的一条 SQL。

可以把不同数据量下的最终 SQL 打印出来，比较 SQL 文本、参数数量和执行计划。如果 SQL 结构随着参数变化明显变化，或者参数为空时退化成全表查询，基本可以确认动态 SQL 是重