• 一个SQL注释引发的线上问题


    最近开始服务拆分,时间将近半个月.测试阶段也非常顺利,没有什么问题.

    但上线之后的第二天,产品就风风火火的来找我们了,一看就是线上有什么问题.我们也不敢说,我们也不敢问,线上的后台商品忽然无法上架了,导致运营的同学删除商品后无法上架新的商品,导致APP的部分商品暂时不可见.

      线上有问题,那么大家就开始迅速排查起来了.这里有一点要说一下,在上线前夕,产品临时添加一个新的需求,商品的搜索状态不可判断这个条件去掉,这个由于紧急而且对于我们来说也就是SQL中的一个条件的问题,也就没有经过测试,直接上线了,主要也是想省点事情,赶上顺风车直接上线,可问题就出在这里!

    贴上部分类似逻辑SQL片段

    select 
       count(1) from 
      product where
      code = #{code}
       and search
    =#{search}
       and kskdsk
    =#{kskdsk}

    此刻产品需求就是search这个条件去掉,那就习惯性的用IDEA快捷键CTRL+/ 来了一个and条件注释

    select 
       count(1)
    from 
       product
    where
       code = #{code}
    #   and search
    =#{search}    and kskdsk=#{kskdsk}

    然后IDEA就很乖巧的给我注释..注释了...,显示状态也是灰色的显示,应该没什么问题了.

    经过紧急的五分钟排查日志,看到了这个异常

      org.springframework.dao.TransientDataAccessResourceException: 
    ### Error querying database.  Cause: java.sql.SQLException: Parameter index out of range (3 > number of parameters, which is 2).
    ### The error may exist in file [/***/***/***Mapper.xml]
    ### The error may involve defaultParameterMap
    ### The error occurred while setting parameters
    ### SQL: select count(1)   from product   where  code = ? #   and search=?  and kskdsk=?  

    毫无疑问,问题肯定是这个SQL导致的问题,我一看,天哪,注释的语句怎么跑到预编译的SQL中了!不是应该忽略吗?很明显,不是预想的那样.首先错误的意思大概就是,我的SQL中只需要两个参数,我传了三个参数进去,有一个参数找不到他的坑位,其次就是这个#号注释导致的问题,没有被忽略,虽然我们在Navicat for MySql中可以用#号,但是预编译不行,他会把注释给编译到SQl中,除非用<!---->这种注释才可以.

    这个注释导致

      一.参数个数不一致,导致多传的参数不知道放在哪里

      二.注释在预编译语句还是当成SQL一部分执行

    分享出来,避免大家踩坑,也同时反映了自己的一部分问题,没有经过测试流程,没有进行系统的自测,下次需要规范流程,避免产生不必要的问题.这虽然是个小问题,但也反映了很多不足.

     
  • 相关阅读:
    CVPR2020:三维实例分割与目标检测
    CVPR2020:视觉导航的神经拓扑SLAM
    使用现代C++如何避免bugs(下)
    使用现代C++如何避免bugs(上)
    蓝牙mesh网络技术的亮点
    电路功能和优点
    ARM的突破:超级计算机和Mac
    所有处理都走向AI
    Wide-Bandgap宽禁带(WBG)器件(如GaN和SiC)市场将何去何从?
    功率半导体碳化硅(SiC)技术
  • 原文地址:https://www.cnblogs.com/zhaoletian/p/11956038.html
Copyright © 2020-2023  润新知