本文主要是介绍XML重复查询一条Sql语句的解决方法，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
《XML重复查询一条Sql语句的解决方法》文章分析了XML重复查询与日志失效问题,指出因DTO缺少@Data注解导致日志无法格式化、空指针风险及参数穿透,进而引发性能灾难,解决方案为在Controll...
一、核心问题：从SQL重复执行到日志失效
1. 首要现象：XML重复查询失效在排查服务性能时发现：
<!-- MyBATis XML片段 --> <select id="List" resultMap="Map"> SELECT * FROM user WHERE name = #{name} <!-- 参数name为null时重复执行相同全表查询 --> &lChina编程t;/select>
症状：
- 相同SQL反复执行
2. 调试暴露第二问题：日志输出异常为定位参数问题，在Controller添加日志：
log.info("请求参数: {}", userListDto); // 打印输入参数却得到：
请求参数: com.domain.dto.uFcNaczHGser.UserListDto@599f4346 // 对象内存地址后果：
- 无法识别空参数来源：日志无法展示实际传入的
name值
二、根因剖析：DTO断裂引发的级联故障
关键断层点分析：
DTO层面：
- 致命缺陷：缺少
@Data导致：toString()未生成 → 日志无法格式化输出getter未生成 → Service层获取name时隐含空指针风险
- 致命缺陷：缺少
文档缺失：字段无注释导致维护成本增加
// UserListDto.Java（问题版本） public class UserListDto { private String name; // 无业务注释 private Integer pageNum; // 未标识必填 }
Controller层面（核心责任方）：
- 未校验入参：直接传递DTO到Service
- 未处理日志：放任对象原始输出
Service/DAO层面：
- 参数未FcNaczHG过滤：XML直接使用
#{name}未判空 → 重复触发全表扫描 - 无缓存机制：相同查询反复访问数据库
- 参数未FcNaczHG过滤：XML直接使用
三、解决方案：修复数据链路
1. DTO层修正（止血点）
@Data // 核心修复！ 生成toString/getter/setter public class StickerLisjavascripttDto { // 增加必要注释 private String name; // 贴纸名称（可空） private Integer pageNum; // 页码（必填）}
2. Controller层加固（责任方修复）
/*FcNaczHG*
* 获取列表信息
*
* @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层的数据责任
DTO是Controller的盔甲：
- 缺失
@Data≈ 解除防御 → 导致日志失效+参数穿透 - 无字段注释 ≈ 丢失地图 → 增加协作成本
- 缺失
日志是指纹采集器：
- 打印对象地址 → 相当于案发现场无痕迹 → 完全丧失调试能力
- 定制化日志格式（如
name={}）→ 直接锁定问题参数
空参数是系统毒药：
- 未在Controller拦截 → 毒药流入Service层
- DAO层无防御 → 数据库成为最终受害者
教训总结：
UserListDto缺失@Data导致：
- 调试黑洞：日志输出无意义地址符
- 安全缺口：空值穿透至DAO层
- 性能灾难：XML重复全表查询
修复本质：在Controller层建立数据安检站（DTO规范+参数校验）
到此这篇关于XML重复查询一条Sql语句的解决方法的文章就介绍到这了,更多相关xml重复查询sql语句内容请搜索编程China编程(www.chinasem.cn)以前的文章或继续浏览下面的相关文章希望大家以后多多支持China编程(www.chinasem.cn)！
这篇关于XML重复查询一条Sql语句的解决方法的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
