暂无图片
暂无图片
23
暂无图片
暂无图片
3
暂无图片

SQL极致优化案例: 利用索引特性进行max/min优化

原创 刘娣 2021-03-16
7828

IS NOT NULL的优化

1. 问题提出

客户系统有这样一条SQL,脱敏后如下:

SELECT NVL(MAX(T1.CREATED),SYSDATE) FROM DUAL LEFT JOIN TEST11 T1
ON T1.OWNER=’OUTLN’ AND OBJECT_TYPE IS NOT NULL;
复制

SQL是TEST11表和DUAL表相关联,WHERE条件中OWNER字段有索引,SQL走了该字段索引范围扫描的执行计划,单次执行逻辑读2117。SQL执行频率非常高,一分钟数万次。执行计划如下:
image.gif

2. 初步优化

WHERE条件有两个【OWNER=’OUTLN’】和【OBJECT_TYPE IS NOT NULL】,查询取出来的字段是CREATED,考虑创建OWNER+OBJECT_TYPE+CREATED三列联合索引,可以消除回表的成本,创建索引后逻辑读由2117降为82。执行计划如下:
image.gif

3. 极致优化探究 – 索引原理

继续分析该SQL, 发现其实从逻辑上来说,SQL仅需要时间列CREATED的最小值,至于其他值是什么并不重要。那么是否有一种方法可以只取出最小值,而忽略掉其他数据呢? 如果可以做到那么逻辑读就会进一步降低。
考虑一下索引的结构:索引由根节点块(root block)、枝块(branch block)和叶子块(leaf block)组成,索引的数据在叶子块里是顺序排列的。也就是说最小值的数据会保存在索引块的最小那一端。理论上来说,完全可以从叶子块的其中一段取一个块,就可以得到特定索引的最小值。
image.gif

4. 简化版取min/max索引优化

为了更好理解,我们把问题简化成取表里CREATED最小值(或者最大值)。
需要取得TEST11表CREATED的最大/最小值:

SELECT MAX(CREATED) FROM TEST11;
复制

假设存在CREATED字段的索引,那么完全可以只取叶子块的最靠边的一个块,就能得到所需要的的值。

下面做一个测试,创建一个测试表:

create table test11 tablespace DATA_TS as select * from dba_objects where rownum <1000;

begin 
for i in 0..10 loop
insert /*+append */into test11 select * from test11;
commit;
end loop;
end;
/
复制

创建一个CREATED的索引,然后运行之前简化的SQL。根据索引原理可以判断应该需要3-4个逻辑读:分别是Root节点开始–>找最右边的Branch(可能是0-2个,根据索引的层级)–>再找到最右边的Leaf Block。
执行如下,结果和我们之前设想的一样,执行计划走的是INDEX FULL SCAN(MIN/MAX)。
image.gif

设想稍微复杂一点场景:假设需要得到的是符合指定的条件的最大CREATED值呢?
如果我们需要取的是符合OWNER = 'OUTLN’的最大CREATED值。SQL如下:

SELECT MAX(CREATED) FROM TEST11 WHERE OWNER = 'OUTLN'; 
复制

如果存在(OWNER,CREATED)组合索引,数据库就可以利用类似的方法只取其中一个叶子节点。执行计划走的是INDEX RANGE SCAN(MIN/MAX),逻辑读是3:
image.gif

那么假如是SELECT MAX(CREATED) FROM TEST11 WHERE OWNER= ‘OUTLN’ AND OBJECT_TYPE =‘TABLE’ ,就需要新的索引(OWNER,OBJECT_TYPE,CREATED)来完成同样的动作。执行计划走的是INDEX RANGE SCAN(MIN/MAX),需要3个逻辑读:
image.gif

也就是说,必须条件中的列和索引前导列完全匹配,然后取的索引里最后一列的MAX/MIN值,它就可以走最优的INDEX RANGE SCAN (MIN/MAX)索引。

5. 转化IS NOT NULL条件到索引中

回到原始的SQL:

SELECT NVL(MAX(T1.CREATED),SYSDATE) FROM DUAL LEFT JOIN TEST11 T1
ON T1.OWNER=’OUTLN’AND OBJECT_TYPE IS NOT NULL;
复制

原始SQL中除了OWNER=’OUTLN’,还有一个OBJECT_TYPE IS NOT NULL,直接创建 (OWNER,OBJECT_TYPE,CREATED)联合索引消耗逻辑读82,并不能达到最优的效果,因为OBJECT_TYPE IS NOT NULL不能对应到索引的一个特定值,执行计划如下:
image.gif

我们需要把OBJECT_TYPE IS NOT NULL的条件固化成一个特定的值,这样就可以匹配索引中的特定值了。SQL需要改写一下:

1) 去掉DUAL, 并不会影响结果集:

SELECT NVL(MAX(T1.CREATED),SYSDATE) FROM TEST11 T1
WHERE T1.OWNER=’OUTLN’AND OBJECT_TYPE IS NOT NULL;
复制

2) 把OBJECT_TYPE IS NOT NULL变成一个特定值,这里用了CASE WHEN,SQL变成:

SELECT MAX(CREATED) FROM TEST11
WHERE OWNER ='OUTLN'
AND CASE WHEN OBJECT_TYPE IS NOT NULL THEN 1 END = 1;
复制

3) 创建一个函数索引。也就是说OBJECT_TYPE IS NOT NULL的记录在索引中存储为1。如下:

CREATE INDEX IDX_TEST11_MAX ON TEST11(OWNER,CASE WHEN OBJECT_TYPE IS NOT NULL THEN 1 END,CREATED) PARALLEL 4 NOLOGGING;
ALTER INDEX IDX_TEST11_MAX NOPARALLEL;
复制

此时执行计划如下,逻辑读降为3:
image.gif

6. 优化结果

为生产SQL创建CASE WHEN索引并改写SQL后逻辑读降为75,并没有走上最优的INDEX RANGE SCAN (MIN/MAX)执行计划,这是因为这种写法MAX(T1.CREATED)被放在最外层,也就是说对MAX的取值是基于关联后的结果集而不是基于TEST11表。
image.gif

SQL是TEST11和DUAL做关联,取NVL(MAX(T1.CREATED),SYSDATE)的值,即使没有数据也会返回SYSDATE的值,去掉DUAL表不影响,去掉DUAL表后SQL逻辑读降为3:
image.gif

最终完成了一个高频SQL从2117到3的极致优化,提升达数百倍。

IS NULL的优化

系统中还发现另一个SQL, 脱敏后SQL如下:

UPDATE TEST T
SET T.TCODE = (SELECT T1.TCODE FROM TEST1 T1 WHERE T.SCODE = T1.SCODE)
WHERE T.TCODE IS NULL
AND EXISTS (SELECT 1 FROM TEST1 T2 WHERE T.SCODE = T2.SCODE)
复制

image.gif

SQL走的是全表扫描的执行计划,TEST表数据量1100万,每次更新数据0条。执行计划最慢的步骤是ID=3的TEST表全表扫描步骤。WHERE条件中TCODE IS NULL可以过滤掉所有数据,但是我们知道NULL值是不存在索引中的,一般情况下IS NULL只能走全表,如果全表数据非常多SQL性能就会很差。和IS NOT NULL同样的思路,能不能让这部分过滤性非常好的NULL值存在索引中呢?

SElECT * FROM TEST WHERE TCODE IS NULL;

no rows selected
复制

也就是换个思路,用个函数把NULL值转为一个表中该字段不存在的固定值(假设0),非NULL值的转为NULL。这样索引中存储的就是原先的NULL值,也就是经过函数转换后的0,这样可以保证索引最小化,因为原本IS NOT NULL的数据不存在其中。
转换如下:CODE IS NULL <==> CASE WHEN TCODE IS NULL THEN 0 END

使用CASE WHEN而不使用NVL(TCODE,0)函数是为了将索引最小化,因为原有的TCODE存在的值不用保存到索引中,同时也不用考虑NVL之后可能和原有的值相同的情况。
复制

创建函数索引并修改原SQL,逻辑读由原来的80多万降为1:

CREATE INDEX IDX_YHEMTEST ON TEST(CASE WHEN TCODE IS NULL THEN 0 END);

UPDATE TEST T
   SET T.TCODE = (SELECT T1.TCODE FROM TEST1 T1 WHERE T.SCODE = T1.SCODE)
 WHERE CASE WHEN T.TCODE IS NULL THEN 0 END = 0
   AND EXISTS (SELECT 1 FROM TEST1 T2 WHERE T.SCODE = T2.SCODE)
复制

image.gif

经优化,该SQL性能提升数万倍。

「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
2人已赞赏
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论

徐孝亮
暂无图片
1年前
评论
暂无图片 0
娣姐牛逼!
1年前
暂无图片 点赞
评论
广州_老虎刘
暂无图片
1年前
评论
暂无图片 4
作者把index range scan(min/max) 和函数索引研究的挺透,厉害! 第一个sql: 看执行计划,object_type是null值的记录基本上没有,根据这个数据分布, 看看能不能不用函数索引,通过怎样的改写,也能得到一个很好的优化? 第二个sql,确实也做到了极致优化(索引小,有点类似pg的条件索引),但是缺点也比较明显,就是这个函数索引只能用来优化is null这类条件的sql,而且还必须改写。 我的建议是创建(tcode,0)联合索引,不需要改写sql,也能实现相同优化效果,只是索引不够小,但是对于其他使用tcode条件的sql,也能用到这个索引. 另外,你说nvl函数建的索引不够小,那么可以用nvl2或decode函数,相比case when的写法还是会简单一点;
1年前
暂无图片 4
评论
筱悦星辰
暂无图片
2年前
评论
暂无图片 0
努力是人生的态度,实力才是你的尊严。
2年前
暂无图片 点赞
评论
暂无图片
获得了26次点赞
暂无图片
内容获得38次评论
暂无图片
获得了11次收藏
目录
  • IS NOT NULL的优化
    • 1. 问题提出
    • 2. 初步优化
    • 3. 极致优化探究 – 索引原理
    • 4. 简化版取min/max索引优化
    • 5. 转化IS NOT NULL条件到索引中
      • 1) 去掉DUAL, 并不会影响结果集:
      • 2) 把OBJECT_TYPE IS NOT NULL变成一个特定值,这里用了CASE WHEN,SQL变成:
      • 3) 创建一个函数索引。也就是说OBJECT_TYPE IS NOT NULL的记录在索引中存储为1。如下:
    • 6. 优化结果
  • IS NULL的优化