一次HASH JION过慢优化(1)

简介: 原创 转载请注明出处 最近我发现生产有一个语句执行比较慢。需要4-5分钟。所以对其进行了优化,优化结果执行只需要不到3秒。语句如下:我发现出问题的部分是select *                  from (select a.

原创 转载请注明出处

最近我发现生产有一个语句执行比较慢。需要4-5分钟。所以对其进行了优化,优化结果执行只需要不到3秒。
语句如下:
我发现出问题的部分是
select *
                  from (select a.test,
                               a.test1,
                               a.test2,
                               a.test3,
                               a.test4,
                               case
                                 when b.test5 = '1' then
                                  b.test6
                                 else
                                  a.test6
                               end test6,
                               0 bankComm,
                               c.test7 || '-' || case
                                 when c.test8= '1' then
                                  '收'
                                 when c.test8= '2' then
                                  '付'
                               end payway,
                               case
                                 when a.poatype = '1' then
                                  a.poainfo
                                 else
                                  ''
                               end,
                               a.test9,
                               b.test10,
                               b.test11,
                               a.test12,
                               a.test13,
                               a.test14,
                               case
                                 when a.test15 = b.test15 then
                                  a.test19
                                 else
                                  a.totest19
                               end,
                               b.totest19,
                               a.totest19,
                               a.totest19
                          from prod.totest19 a,
                               prod.totest19 b,
                               prod.totest19        c
                         where (a.totest15 = b.test15 or
                               a.test15 = b.test15)
                           and b.totest19 not in ('50', '51', '60', '61')
                           and c.totest19 = '1'
                           and c.totest19 = '1'
                           and b.totest19 = c.paywaycode
                           and b.totest19 '212'
                           AND to_char(a.test, 'yyyy-mm-dd') >=
                               '2011-01-11'
                           AND to_char(a.test, 'yyyy-mm-dd')                                '2011-01-12'
执行计划如下:
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 3443708996
--------------------------------------------------------------------------------
| Id  | Operation             | Name              | Rows  | Bytes |TempSpc| Cost
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |                   |   808 |   183K|       |  775
|*  1 |  HASH JOIN            |                   |   808 |   183K|  2648K|  775
|   2 |   MERGE JOIN CARTESIAN|                   | 13655 |  2480K|       |  677
|*  3 |    TABLE ACCESS FULL  | test3|   846 |   128K|       |  584
|   4 |    BUFFER SORT        |                   |    16 |   480 |       |   93
|*  5 |     TABLE ACCESS FULL | test2       |    16 |   480 |       |
|*  6 |   TABLE ACCESS FULL   | test | 46215 |  2121K|       |   51

相关文章
|
3月前
|
存储 关系型数据库 MySQL
MySQL索引失效及避免策略:优化查询性能的关键
MySQL索引失效及避免策略:优化查询性能的关键
377 3
|
7月前
|
缓存 关系型数据库 MySQL
MySQL查询优化:提速查询效率的13大秘籍(合理使用索引合并、优化配置参数、使用分区优化性能、避免不必要的排序和group by操作)(下)
MySQL查询优化:提速查询效率的13大秘籍(合理使用索引合并、优化配置参数、使用分区优化性能、避免不必要的排序和group by操作)(下)
315 0
|
5月前
|
SQL 算法 数据库
SQL优化器原理 - Join重排
保证等价性:不同的Join顺序可能产生相同的结果集,但执行成本可能不同。因此,在重排Join顺序时,必须确保结果集的等价性。
|
5月前
|
SQL 算法 数据库
SQL优化器原理 - Join重排。
保证等价性:不同的Join顺序可能产生相同的结果集,但执行成本可能不同。因此,在重排Join顺序时,必须确保结果集的等价性。
|
存储 关系型数据库 MySQL
索引下推,这个点你肯定不知道!
索引下推(Index Condition Pushdown) ICP 是Mysql5.6之后新增的功能,主要的核心点就在于把数据筛选的过程放在了存储引擎层去处理,而不是像之前一样放到Server层去做过滤。 虽然这是一个比较简单的概念,但是可能很多不细心的同学对于索引下推会存在一个小小的误区,至于是什么,请看下文。
索引下推,这个点你肯定不知道!
|
存储 SQL 缓存
为什么索引可以让查询变快?终于有人说清楚了!
上表是一张真实的数据库表,其中每一行是一条记录,每条记录都有字段。假设上面的数据库是一个有10万条记录的大数据库。现在,我们想从10万条记录中搜索一些内容,那么挨着一个一个搜索无疑将花费很长的时间,这个时候我们在数据结构与算法里学的二分查找法就派上了用场。
为什么索引可以让查询变快?终于有人说清楚了!
|
SQL 关系型数据库
冗余数据JOIN导致的慢SQL优化一例
CASE 一个这样的查询,每个表都只有几千条数据,但是查询非常慢,几十秒不出结果。 select distinct abc.pro_col1, abc.col3 from t0 p INNER JOIN t1 abc on p.id=abc.par_col2
4849 0
|
SQL 索引