sql - Performance update in Aggregate query

Question

I would like to improve the performance of the following in aggregate query.

On T_Search_Detail with 30 million records, below Query takes 12 seconds to execute? can it be written better, suggestions to improve performance?

Explain Plan:

Execution Plan
----------------------------------------------------------
Plan hash value: 651646209
--------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name            | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |                 |     3 |    42 | 27948   (1)| 00:05:36 |
|   1 |  SORT GROUP BY                 |                 |     3 |    42 | 27948   (1)| 00:05:36 |
|   2 |   VIEW                         |                 |    56 |   784 | 27947   (1)| 00:05:36 |
|   3 |    HASH GROUP BY               |                 |    56 |  1344 | 27947   (1)| 00:05:36 |
|*  4 |     TABLE ACCESS BY INDEX ROWID| T_SEARCH_DETAIL |   898 | 21552 | 27946   (1)| 00:05:36 |
|*  5 |      INDEX RANGE SCAN          | INDEX_CREATE_DT |  1254K|       |  3451   (1)| 00:00:42 |
--------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   4 - filter("TSD"."MATCH_SOURCE" IS NOT NULL AND "TSD"."MATCH_TYPE" IS NOT NULL AND
              "TSD"."MATCH_TYPE" LIKE '%Exact%')
   5 - access("TSD"."CREATE_DT">=TO_DATE(' 2012-12-11 00:00:00', 'syyyy-mm-dd
              hh24:mi:ss') AND "TSD"."CREATE_DT"<TO_DATE(' 2013-04-23 00:00:00', 'syyyy-mm-dd
              hh24:mi:ss'))

Table DDL: enter image description here

This query uses two tables T_Search and T_Search_detail, with FOREIGN_KEY as match_id.

SELECT   ms,
         SUM(ct)
FROM     ( SELECT  tsd.match_source    ms,
                  tsd.match_type       mt,
                  COUNT(tsd.search_id) ct
         FROM     t_search ts,
                  t_search_detail tsd
         WHERE    tsd.match_source IS NOT NULL
         AND      tsd.match_type   IS NOT NULL
         AND      ts.match_id                = tsd.match_id
         AND      tsd.match_type          LIKE '%Exact%'
         AND
                  (
                           tsd.create_dt >= to_date('12/11/2012', 'MM/DD/YYYY')
                  AND      tsd.create_dt  < (to_date('04/22/2013', 'MM/DD/YYYY')+1)
                  )
         GROUP BY tsd.match_source,
                  tsd.match_type
         )
GROUP BY ms
ORDER BY ms DESC

score 2 · Accepted Answer

如果值得通过索引访问“%Exact%”行，那么您可以使用基于函数的索引来实现：

create index ... on ... (case Coalesce(InStr(match_type,'Exact'),0) when 0 then null else 1 end)

这将仅在索引中包含匹配类型包含字符串“Exact”的行，并且您将查询：

where ... and
      (case Coalecse(InStr(match_type,'Exact'),0) when 0 then null else 1 end) = 1

您可以将“精确”搜索与日期索引结合起来：

create index ... on ... (case Coalesce(InStr(match_type,'Exact'),0) when 0 then null else create_dt end)

...它只会为 match_type 包括“Exact”的行索引 create_dt。

你会查询：

case Coalesce(InStr(match_type,'Exact'),0) when 0 then null else create_dt end >= to_date('12/11/2012', 'MM/DD/YYYY') and
case Coalesce(InStr(match_type,'Exact'),0) when 0 then null else create_dt end  < (to_date('04/22/2013', 'MM/DD/YYYY')+1)

score 1 · Accepted Answer

首先，您所做的事情不需要两个级别的聚合。您可以汇总match_source并计算匹配记录的数量。

这是查询的简化版本，使用正确的连接语法：

SELECT  tsd.match_source ms, COUNT(tsd.search_id) ct
FROM t_search ts join
     t_search_detail tsd
     on ts.match_id = tsd.match_id
WHERE tsd.match_source IS NOT NULL AND
      tsd.match_type   IS NOT NULL AND
      tsd.match_type LIKE '%Exact%' and
      tsd.create_dt >= to_date('12/11/2012', 'MM/DD/YYYY') and
      tsd.create_dt  < (to_date('04/22/2013', 'MM/DD/YYYY')+1)
GROUP BY tsd.match_source;

接下来，看起来该表t_search根本没有被使用。它可能用于过滤，也可能会增加行数。但是，假设中的所有内容都t_search_detail与中的一行完全匹配t_search，那么您有：

SELECT  tsd.match_source ms, COUNT(tsd.search_id) ct
FROM t_search_detail tsd
WHERE tsd.match_source IS NOT NULL AND
      tsd.match_type   IS NOT NULL AND
      tsd.match_type LIKE '%Exact%' and
      tsd.create_dt >= to_date('12/11/2012', 'MM/DD/YYYY') and
      tsd.create_dt  < (to_date('04/22/2013', 'MM/DD/YYYY')+1)
GROUP BY tsd.match_source;

有了这个，您可能会使用以下索引来提高性能t_search_detail(match_source, match_type, create_dt)：

CREATE INDEX tsearchdetail_matchsource_matchtype_createdt
         ON t_search_detail(match_source, match_type, create_dt);

看来此查询将不得不搜索与日期匹配的所有记录。match_type您可以将表单列表扩展为'%EXACT%'有限列表吗？如果是这样，则将该行更改where为：

where . . . and match_type in (<list of exact match types>) . . .

然后你想要一个关于(match_type, create_dt). 但是，只有在大多数匹配类型不是“精确”的情况下，这才会显着提高性能——您可能只是处于必须处理大量记录的位置，这可能需要几秒钟。

score 0 · Accepted Answer

除了 SQL 调整本身之外，在查询执行期间（以及之后的 v$sql_workarea）监视 v$sql_workarea_active 以查看您的查询是否正在使用临时表空间进行存储，如果是，您是在执行单遍操作还是多遍操作。

多通道操作是性能杀手，您需要确保调整内存大小以避免这些操作，最好避免单通道操作。为此，您可能必须将会话切换到手动内存管理，或者通过各自的缓存顾问视图查看 PGA 和 SGA 大小的总体分配。

http://docs.oracle.com/cd/E11882_01/server.112/e16638/memory.htm#i49320

sql - Performance update in Aggregate query

3 回答 3

Related

Reference