XML重复查询一条Sql语句？？怎么解决

一、核心问题：从SQL重复执行到日志失效

1. 首要现象：XML重复查询失效
在排查服务性能时发现：

<!-- MyBatis XML片段 -->
<select id="List" resultMap="Map">    
SELECT * FROM user WHERE name = #{name}     
<!-- 参数name为null时重复执行相同全表查询 -->
</select>

症状：

• 相同SQL反复执行 

2. 调试暴露第二问题：日志输出异常
为定位参数问题，在Controller添加日志：

log.info("请求参数: {}", userListDto); // 打印输入参数

却得到：

请求参数: com.domain.dto.user.UserListDto@599f4346  // 对象内存地址

后果：

• 无法识别空参数来源：日志无法展示实际传入的name值

---

二、根因剖析：DTO断裂引发的级联故障

关键断层点分析：

1. DTO层面：

   • 致命缺陷：缺少@Data导致：
     • toString()未生成 → 日志无法格式化输出
     • getter未生成 → Service层获取name时隐含空指针风险
   • 文档缺失：字段无注释导致维护成本增加

     // UserListDto.java（问题版本）
     public class UserListDto {    
     private String name;   // 无业务注释    
     private Integer pageNum;  // 未标识必填
     }

2. Controller层面（核心责任方）：

   • 未校验入参：直接传递DTO到Service
   • 未处理日志：放任对象原始输出

3. Service/DAO层面：

   • 参数未过滤：XML直接使用#{name}未判空 → 重复触发全表扫描
   • 无缓存机制：相同查询反复访问数据库

---

三、解决方案：修复数据链路

1. DTO层修正（止血点）

@Data // 核心修复！
生成toString/getter/setter
public class StickerListDto {    
// 增加必要注释    private String name;       
// 贴纸名称（可空）    private Integer pageNum;   
// 页码（必填）}

2. Controller层加固（责任方修复）

<JAVA>

/*** 获取列表信息** @param dto 请求参数封装对象* @return 贴纸列表信息*/
public TableDataInfo<UserListVo> getUserList(UserListtDto dto) {// 关键日志完善 → 打印完整且精准的参数信息log.info("请求获取贴纸列表，参数为：Name = {}, PageNum = {}", dto.getName(), dto.getPageNum() == null ? "null" : dto.getPageNum());// 参数校验增强 → 细化校验逻辑，全面检查参数合法性if (dto == null) {throw new IllegalArgumentException("请求参数整体为空，无法进行查询");}if (dto.getPageNum() == null || dto.getPageNum() < 1) {throw new IllegalArgumentException("页码参数异常，必须为大于等于1的正整数");}// 补充对其他关键参数的校验示例（按实际需求调整）if (dto.getName() != null && dto.getName().length() > 50) {throw new IllegalArgumentException("名称参数过长，长度不得超过50字符");}// 正常业务逻辑调用 → 参数已校验，可安全传递给服务层处理return productStickerService.getStickerList(dto);
}

---

四、核心经验：Controller层的数据责任

1. DTO是Controller的盔甲：

   • 缺失@Data ≈ 解除防御 → 导致日志失效+参数穿透
   • 无字段注释 ≈ 丢失地图 → 增加协作成本

2. 日志是指纹采集器：

   • 打印对象地址 → 相当于案发现场无痕迹 → 完全丧失调试能力
   • 定制化日志格式（如name={}）→ 直接锁定问题参数

3. 空参数是系统毒药：

   • 未在Controller拦截 → 毒药流入Service层
   • DAO层无防御 → 数据库成为最终受害者

教训总结：
UserListDto缺失@Data导致：

• 调试黑洞：日志输出无意义地址符
• 安全缺口：空值穿透至DAO层
• 性能灾难：XML重复全表查询
  修复本质：在Controller层建立数据安检站（DTO规范+参数校验）