zoukankan      html  css  js  c++  java
  • 一条垃圾SQL,把 64 核 CPU 快跑崩了!

    最近系统出了一个严重问题,应用程序卡崩导致不可用,把 Oracle 数据库服务器 64 核 CPU 快被跑满了:

     

    经定位,是因为一条垃圾 SQL 引起的!!

    其实也就是一条很简单的 SQL:

    select .. from xxx where xx_no = 20200400001
    

      

    为了信息安全,以上 SQL 经过处理。

    其实就是根据 XX_NO 查询一 条数据,然后查询条件和字段数据类型不一致,结果隐式转换导致索引失效而全表扫描……

    • 字段类型为:NVARCHAR2
    • 查询条件类型为:NUMBER

    这也是老生常谈的问题了,MySQL 也有同样的问题,SQL很简单,问题很严重!!!

    来看下数据类型不一致时的 Oracle 的查询解释计划:

    select .. from xxx where xx_no = 20200400001
    

      

    结果:导致隐式转换,全表扫描

    当字段类型和查询条件数据类型不一致的时候,如果没有转换函数,就会默认隐式转换,当数据类型不能隐式转换时就会报错。

    再看下数据类型一致时的 Oracle 的查询解释计划:

    select .. from xxx where xx_no = '20200400001'
    

      

     

    结果:唯一索引扫描

    再看下两个 SQL 的 IO、CPU 耗费,全表扫描和走唯一索引时的效率真是差距太大,全表扫描是大忌!

    还好这个表的数据不是很大,不然后果会不堪设想。。

    所以在工作中,应该要避免隐式转换,要使用显式转换(转换函数,),遵循 "字段是什么类型,就用什么类型的" 的原则,多用查询分析器检查下。

     

    原文:https://blog.csdn.net/youanyyou/article/details/105489594

  • 相关阅读:
    「SHOI2015」脑洞治疗仪
    LOJ 数列分块入门 8
    CF932F Escape Through Leaf
    NOIP2021游记总结
    [HEOI2016/TJOI2016]序列
    【模板】动态树(Link Cut Tree)
    LG P2839 [国家集训队]middle
    JZOJ 7377.欢乐豆
    JZOJ 7392. 【2021.11.17NOIP提高组联考】数 (ds)
    LOJ 数列分块入门 6
  • 原文地址:https://www.cnblogs.com/sucretan2010/p/13778140.html
Copyright © 2011-2022 走看看