当前位置: 代码网 > it编程>数据库>MsSqlserver > XML重复查询一条Sql语句的解决方法

XML重复查询一条Sql语句的解决方法

2025年06月23日 MsSqlserver 我要评论
一、核心问题:从sql重复执行到日志失效1. 首要现象:xml重复查询失效在排查服务性能时发现:<!-- mybatis xml片段 --><select id="list" res

一、核心问题:从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断裂引发的级联故障

关键断层点分析

  • dto层面:

    • 致命缺陷:缺少@data导致:
      • tostring()未生成 → 日志无法格式化输出
      • getter未生成 → service层获取name时隐含空指针风险

文档缺失:字段无注释导致维护成本增加

// userlistdto.java(问题版本)
public class userlistdto {    
private string name;   // 无业务注释    
private integer pagenum;  // 未标识必填
}
  • controller层面(核心责任方)

    • 未校验入参:直接传递dto到service
    • 未处理日志:放任对象原始输出
  • service/dao层面

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

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

1. dto层修正(止血点)

@data // 核心修复!
生成tostring/getter/setter
public class stickerlistdto {    
// 增加必要注释    private string name;       
// 贴纸名称(可空)    private integer pagenum;   
// 页码(必填)}

2. controller层加固(责任方修复)

/**
 * 获取列表信息
 *
 * @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语句内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网!

(0)

相关文章:

版权声明:本文内容由互联网用户贡献,该文观点仅代表作者本人。本站仅提供信息存储服务,不拥有所有权,不承担相关法律责任。 如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 2386932994@qq.com 举报,一经查实将立刻删除。

发表评论

验证码:
Copyright © 2017-2025  代码网 保留所有权利. 粤ICP备2024248653号
站长QQ:2386932994 | 联系邮箱:2386932994@qq.com