SQL性能优化 - 避免使用 IN 和 NOT IN

WHY?

IN 和 NOT IN 是比较常用的关键字,为什么要尽量避免呢?

1、效率低 

项目中遇到这么个情况:

t1表 和 t2表  都是150w条数据,600M的样子,都不算大。

但是这样一句查询 ↓

select * from t1 where phone not in (select phone from t2)


直接就把我跑傻了。。。十几分钟,检查了一下  phone在两个表都建了索引,字段类型也是一样的。原来not in 是不能命中索引的。。。。

改成 NOT EXISTS 之后查询 20s ,效率真的差好多。

 select * from t1 
 where  not  EXISTS (select phone from t2  where t1.phone =t2.phone)

2、容易出现问题,或查询结果有误 (不能更严重的缺点)

以 IN 为例。建两个表:test1 和 test2

create table test1 (id1 int)
create table test2 (id2 int)

insert into test1 (id1) values (1),(2),(3)
insert into test2 (id2) values (1),(2)

我想要查询,在test2中存在的  test1中的id 。使用IN的一般写法是:

select id1 from test1 
where id1 in (select id2 from test2)

结果是:

  OK 木有问题!

但是如果我一时手滑,写成了:

select id1 from test1 
where id1 in (select id1 from test2)

不小心把id2写成id1了 ,会怎么样呢?

结果是:

 EXCUSE ME! 为什么不报错? 

单独查询 select id1 from test2 是一定会报错: 消息 207,级别 16,状态 1,第 11 行 列名 'id1' 无效。

然而使用了IN的子查询就是这么敷衍,直接查出 1 2 3

这仅仅是容易出错的情况,自己不写错还没啥事儿,下面来看一下 NOT IN 直接查出错误结果的情况:

给test2插入一个空值:

insert into test2 (id2) values (NULL)

我想要查询,在test2中不存在的  test1中的id 。

select id1 from test1 
where id1 not in (select id2 from test2)

结果是:

 空白! 显然这个结果不是我们想要的。我们想要3。为什么会这样呢?

原因是:NULL不等于任何非空的值啊!如果id2只有1和2, 那么3<>1 且 3<>2 所以3输出了,但是 id2包含空值,那么 3也不等于NULL 所以它不会输出。

(跑题一句:建表的时候最好不要允许含空值,否则问题多多。)

HOW?

1、用 EXISTS 或 NOT EXISTS 代替

select *  from test1 
   where EXISTS (select * from test2  where id2 = id1 )

select *  FROM test1  
 where NOT EXISTS (select * from test2  where id2 = id1 )

2、用JOIN 代替

 select id1 from test1 
   INNER JOIN test2 ON id2 = id1 
   
 select id1 from test1 
   LEFT JOIN test2 ON id2 = id1 
   where id2 IS NULL

妥妥的没有问题了!

PS:那我们死活都不能用 IN 和 NOT IN 了么?并没有,一位大神曾经说过,如果是确定且有限的集合时,可以使用。如 IN (0,1,2)。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
oracle的sql优化方法 1.全表扫描和索引扫描   大数据量表尽量要避免全表扫描,全部扫描会按顺序每条记录扫描,对于>100万数据表影响很大。   Oracle中通过RowID访问数据是最快的方式   对字段进行函数转换,或者前模糊查询都会导致无法应用索引而进行全表扫描   对Oracle共享池和缓冲区中的Sql必须要大小写都完全用上才能够匹配上 2.顺序问题   Oracle按照从右到左的顺序对数据表进行解析。因此From最后面的表为基础表,一般要选择记录数最少的表作为基础表。   对于Where条件的顺序,过滤到最大查询记录数量的条件必须写在Where条件的结尾处。   Where条件中涉及到使用复杂函数判定的必须注意要写到Where条件的最前面 3.索引方面   记录数少的表保留有主键索引就可以了,不要再去建其它索引,全表扫描也很快   索引最好单独建立表空间,必要时候对索引进行重建   必要时候可以使用函数索引,但不推荐使用   Oracle中的视图也可以增加索引,但一般不推荐使用   *Sql语句中大量使用函数时候会导致很多索引无法使用上,要针对具体问题分析 4.其它   避免使用Select *,因为系统需要去帮你将*转换为所有的列名,这个需要额外去查询数据字典。   Count(1)和Count(*)差别不大。   多使用Decode函数来作简单的代码和名称间的转换,以减少表关联   使用Truncate替代delete来删除记录,但Truncate数据不记录日志,无法进行回滚   对于复杂的存储过程可以多次提交的数据的要多分多次Commit,否则长事务对系统性能影响很大   Distinct和Having子句都是耗时操作,应该尽可能少使用   在不需要考虑重复记录合并时候用Union All来代替Union   使用显性游标而不使用隐性游标,特别是大数据量情况下隐性游标对性能影响很大   是否使用函数的问题   用直接的表关联来代替Exist.用Exist或Not Exists来代理In。In进行子查询效率很差。 5.SQL语句分析   通过SQLPLUS中的SET TRACE 功能对Sql语句的性能进行分析   通过Toad或PL/SQL Developer对语句的性能进行和索引的使用情况进行分析   对Oracle缺省的优化不满意可以强制使用Hint,但一般不推荐使用   对Flag等只存储是或否信息的字段,一般不推荐建立索引。必要可以采用位图索引   *存在递归查询情况如果关联Table太多对性能会造成较大影响,往往推荐采用临时表转为分步骤操作提高性能   *尽量使用表关联查询而不使用函数,但涉及类似于代码表要重复关联多次取数据问题时候又适合使用函数
SQL性能优化技术总结: 从I/O的观点来看,使用索引没有意义时建议使用全表扫描 如果查询中包含了子查询,那么注意首先优化子查询 注意关联子查询,尽量减少关联子查询的使用,因为它的代价很高,并且非常消耗CPU 在Sql语句中使用not exists 代替 not in 用表连接替换EXISTS 使用带有前导字段的like来替换substr函数 考虑使用union all代替多个or连接操作 如果经常执行主细表的联合查询,建立外键索引 考虑使用非唯一索引支持唯一性约束条件 主动的确定使用循环嵌套、合并连接、散列连接,尽可能测试使用一种代价较小的连接方式。 如果需要在pl/sql 程序中使用动态sql,建议使用execute immediate 对于非常大的表,考虑使用表和索引的分区 如果需要在创建索引的时候减少所需时间,可以在会话集设置比较大的sort_area_size 考虑更多的使用decode函数,而不是在pl/sql中作判断 一定要周期性的收集信息,及时发现系统中的潜在问题 选择最有效率的驱动表 很多情况下ORACLE并不能为我们的SQL语句选择最有效的驱动表, 在我们自己确定了合适的驱动表之后,可以使用HINT: ORDERED,LEADING来指定合适的驱动表 WHERE子句中的连接条件书写顺序 那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾 减少对表的访问次数 (减少逻辑读) 避免索引列的类型 隐式转换造成的索引无效

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值