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规范+参数校验)
相关推荐
码农阿豪1 小时前
国产化替代新篇章:金仓数据库如何实现MongoDB平滑迁移
数据库·mongodb
彦偈1 小时前
Centos7 oracle 11G 搭建ADG
数据库·oracle
言德斐8 小时前
SQL性能优化的思路及策略
数据库·sql·性能优化
码界奇点8 小时前
Django视图从基础到高级的全面解析
数据库·django·sqlite·web·python3.11
Allan_20259 小时前
数据库学习
数据库·学习
fen_fen9 小时前
人大金仓数据库kingbase8创建表示例
数据库·oracle
一勺菠萝丶9 小时前
「您的连接不是私密连接」详解:为什么 HTTPS 证书会报错,以及如何正确配置子域名证书
数据库·网络协议·https
²º²²এ松9 小时前
蓝牙低功耗(BLE)通信的中心设备/外围设备(连接角色)、主机/从机(时序角色)、客户端/服务器(数据交互角色)的理解
运维·服务器·数据库
百锦再9 小时前
Vue Scoped样式混淆问题详解与解决方案
java·前端·javascript·数据库·vue.js·学习·.net
数据库知识分享者小北10 小时前
云栖重磅|瑶池数据库:从云原生数据底座向“AI就绪”的多模态数据底座演进
数据库·人工智能·云原生