导读 | 在 DBA 所优化的数据库环境中,绝大多数性能问题其实是由于 SQL 编写不当导致的。SQL 的世界无奇不有,今天我们一起见识一条让你绝对想吐血的杀手SQL。 |
某保险客户,ETL 耗时数个小时,我们做了sql report发现压力主要在其中一个SQL上。
单次执行时间:5788(秒)
单次逻辑读:10亿(块)
单次返回行数:21万(行)
我们首先看SQL语句,因为比较长,此处只节选部分的
查看其执行计划:
我们主要关注一下从7到16行:发现存在两次全表扫描。中间做了一次filter。
多年的经验告诉我,两个全表扫组成的Filter ,问题很严重, 因为涉及数据逐条处理。 而这个执行计划里,被驱动表还是全表扫。
Not In/In 操作有时候的确会产生 Filter操作,在11g之前的版本,要把not in 语句转换成反连接,not in条件的列必须有Not null 属性,或者语句中带入了not null的限制,否则只能采用Filter,逐条过滤.
我们举例说明一下:
查看T_OBJ的属性:
发现有在三列上都没有not null的限制。
我们此时伪装成10G的优化器。