我想优化使用 IN 子句和 regex_str 函数的存储过程。我不确定我应该如何进一步优化它?

Posted

技术标签:

【中文标题】我想优化使用 IN 子句和 regex_str 函数的存储过程。我不确定我应该如何进一步优化它?【英文标题】:I want to optimize a stored procedure that uses IN clause and a regex_str function. I am not sure that how I should optimize it more? 【发布时间】:2012-09-25 07:36:04 【问题描述】:

我得到的响应时间约为 200 毫秒。 我想进一步优化它。 我怎样才能做到这一点?

CREATE OR REPLACE
PROCEDURE GETSTORES
(
LISTOFOFFERIDS IN VARCHAR2,
REF_OFFERS OUT TYPES.OFFER_RECORD_CURSOR
)
AS
BEGIN
  OPEN REF_OFFERS FOR
  SELECT
  /*+ PARALLEL(STORES 5) PARALLEL(MERCHANTOFFERS 5)*/
  MOFF.OFFERID,
  s.STOREID,
  S.LAT,
  s.LNG
  FROM
  MERCHANTOFFERS MOFF
  INNER JOIN STORES s ON MOFF.STOREID =S.STOREID
  WHERE
  MOFF.OFFERID IN
  (
    SELECT
      REGEXP_SUBSTR(LISTOFOFFERIDS,'[^,]+', 1, LEVEL)
    FROM
      DUAL CONNECT BY REGEXP_SUBSTR(LISTOFOFFERIDS, '[^,]+', 1, LEVEL) IS NOT NULL
  )
  ;
END
GETSTORES;

我正在使用 regex_substr 从 LISTOFOFFERIDS 中的逗号分隔字符串中获取 OfferID 列表。 我已经在 Stores 表的 STOREID 上创建了索引,但无济于事。 如果速度更快,实现相同目标的新方法也很好。

相同的类型声明:

create or replace

    PACKAGE TYPES
    AS
    TYPE OFFER_RECORD
    IS
      RECORD(
      OFFER_ID MERCHANTOFFERS.OFFERID%TYPE,
      STORE_ID STORES.STOREID%TYPE,
      LAT STORES.LAT%TYPE,
      LNG STORES.LNG%TYPE
      );
    TYPE OFFER_RECORD_CURSOR
    IS
      REF
      CURSOR
        RETURN OFFER_RECORD;
      END
      TYPES;

选择计划揭示了以下信息:

Plan hash value: 1501040938

-------------------------------------------------------------------------------------------------------------
| Id  | Operation                                  | Name           | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                           |                |   276 | 67620 |    17  (12)| 00:00:01 |
|*  1 |  HASH JOIN                                 |                |   276 | 67620 |    17  (12)| 00:00:01 |
|   2 |   NESTED LOOPS                             |                |       |       |            |          |
|   3 |    NESTED LOOPS                            |                |   276 | 61272 |     3  (34)| 00:00:01 |
|   4 |     VIEW                                   | VW_NSO_1       |     1 |   202 |     3  (34)| 00:00:01 |
|   5 |      HASH UNIQUE                           |                |     1 |       |     3  (34)| 00:00:01 |
|*  6 |       CONNECT BY WITHOUT FILTERING (UNIQUE)|                |       |       |            |          |
|   7 |        FAST DUAL                           |                |     1 |       |     2   (0)| 00:00:01 |
|*  8 |     INDEX RANGE SCAN                       | OFFERID_INDEX  |   276 |       |     0   (0)| 00:00:01 |
|   9 |    TABLE ACCESS BY INDEX ROWID             | MERCHANTOFFERS |   276 |  5520 |     0   (0)| 00:00:01 |
|  10 |   TABLE ACCESS FULL                        | STORES         |  9947 |   223K|    13   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("MERCHANTOFFERS"."STOREID"="STORES"."STOREID")
   6 - filter( REGEXP_SUBSTR ('M1-Off2,M2-Off5,M2-Off9,M5-Off4,M10-Off1,M1-Off3,M2-Off4,M3-Off2,M4-Of
              f6,M5-Off1,M6-Off1,M8-Off1,M7-Off3,M1-Off1,M2-Off1,M3-Off1,M3-Off4,M3-Off5,M3-Off6,M4-Off1,M4-Off7,M2
              -Off2,M3-Off3,M5-Off2,M7-Off1,M7-Off2,M1-Off7,M2-Off3,M3-Off7,M5-Off5,M4-Off2,M4-Off3,M4-Off5,M8-Off2
              ,M6-Off2,M1-Off5,M1-Off6,M1-Off9,M1-Off8,M2-Off6,M2-Off7,M4-Off4,M9-Off1,M6-Off4,M1-Off4,M1-Off10,M2-
              Off8,M3-Off8,M6-Off3,M5-Off3','[^,]+',1,LEVEL) IS NOT NULL)
   8 - access("MERCHANTOFFERS"."OFFERID"="$kkqu_col_1")

【问题讨论】:

能发一下select的解释方案吗? 选择方案如?你想要类型声明吗?我已经编辑了帖子以包含它。 Oracle 解释计划。 http://docs.oracle.com/cd/B10500_01/server.920/a96533/ex_plan.htm 我已经编辑了帖子并包含了计划。谢谢:) 好的。看来您需要商店索引(STOREID) 【参考方案1】:
    如果您的服务器支持它(似乎您想要它),请将提示更改为/*+ PARALLEL(S 8) PARALLEL(MOFF 8)*/。当您有别名时,您必须在提示中使用别名。 你应该试试APC(STORES(STOREID, LAT, LNG))推荐的复合索引 请回答问题:对于给出的示例,您获得了多少不同的商店 (select count(distinct storeid) from (your_query)) 以及 STORES 表中有多少家商店? (Select count(*) from Stores)? 你分析过dbms_stats.gather_table_stats的表格吗? 我相信connect by 查询不是问题所在。运行时间为 0.02 秒。

【讨论】:

哦,我当时没有得到这个问题。 distinct查询返回9946,总数也是9946。查询返回13970条记录,是offer和store的join。报价总数为 13971。关于复合索引,我在所有这些字段上都有单独的索引,我应该将它们组合起来吗?分析后如何查看收集到的统计数据? 9946?哎哟。什么返回select count(*) from MERCHANTOFFERS?我认为您所能做的就是放置并行提示(/*+ PARALLEL(S 8) */)。 似乎复合索引不会太有用。您需要阅读整个表格STORES。表 Stores 包含长列作为描述等? 没有商店只有三个字段 ID 和 Lat 和 Lng 从 MERCHANTOFFERS 返回 select count(*) 是什么?我认为您所能做的就是放置并行提示( /*+ PARALLEL(S 8) */)。【参考方案2】:

如果你看一下你解释的计划,每个步骤的时间安排是相同的:没有明显的候选人可以专注于调整。

您发布的示例有 50 个 OFFERID 令牌。那是代表吗?他们映射到 276 家商店——这是一个代表性的比例吗?是否有任何优惠适用于多个商店?

276 行约占行数的 2.7%,这是一个很小的 ​​sliver:但是,由于 STORES 似乎是一个非常紧凑的表,因此索引读取是否比全表扫描快是微不足道的。

要从数据库中榨取更多汁液,唯一明显的做法就是在 STORES(STOREID, LAT, LNG) 上构建复合索引;大概它不是一个看到很多 DML 的表,因此额外索引的开销不会太多。

最后一点:您的查询在 0.2 秒内执行。那么你希望它快多少呢?

【讨论】:

您好,感谢您的回复!我想把它带到0.1ms左右。您可以建议任何其他方法吗?就像使用函数而不是 Stored proc .. 或任何东西一样......这里有点绝望:( 函数是一个返回值的存储过程。它不会有不同的性能配置文件。 “这里有点绝望” 但还不足以回答我关于数据量或偏差的问题。另外,你试过我建议的复合索引吗? 抱歉当时正在开会。是的,优惠可以打到不止一家商店。 50 个令牌不代表它只是一个随机数。在运行时,我们可以提供从 1 到 1000 的报价。还有其他方法可以更优化地实现 IN 查询吗?【参考方案3】:

考虑在连接中删除正则表达式,这样连接可以快速发生。 如果连接列上有索引,则连接可能会从嵌套循环中移动 到某种散列连接。

一旦你有了那个结果集(希望行更少),然后用你的正则表达式过滤它。

您可能会发现 WITH 语句在这个场景中很有帮助。

按照这个顺序的东西。 (未经测试的例子)

WITH
base AS
(
    SELECT /*+ PARALLEL(STORES 5) PARALLEL(MERCHANTOFFERS 5) */
           moff.OFFERID,
              s.STOREID,
              s.LAT,
              s.LNG
    FROM MERCHANTOFFERS moff
    INNER JOIN STORES s 
    ON MOFF.STOREID = S.STOREID
),
offers AS
(
    SELECT REGEXP_SUBSTR(LISTOFOFFERIDS,'[^,]+', 1, LEVEL) offerid
    FROM DUAL 
    CONNECT BY REGEXP_SUBSTR(LISTOFOFFERIDS, '[^,]+', 1, LEVEL) IS NOT NULL
)
SELECT base.*
FROM base,
     offers
WHERE base.offerid = offers.offerid

Oracle 可以将这两个视图执行到内存表中,然后连接。

没有担保人。您的里程可能会有所不同。你在寻找想法。这是一个想法。 祝你好运。

如果我没记错提示章节,当您为表名设置别名时,您需要在提示中使用该别名。 /*+ PARALLEL(s 5) PARALLEL(moff 5) */

我很好奇您为什么决定将值 5 作为提示。我的印象是 Oracle 会根据系统负载和其他神秘情况为其选择最佳价值。

【讨论】:

临时表写入磁盘。因此,这种方法极不可能将性能提高 0.1 秒。 取决于表的大小。 嗨 EvilTech .. 你能告诉我以后如何应用正则表达式吗?正则表达式实际上将逗号分隔列表分隔为 IN 子句中可接受的列表......还有其他更好的方法吗? 我相信connect by 查询不是问题所在。它在 0.02 秒内运行。 嗯 .. 但是 IN 子句的任何替代方案?

以上是关于我想优化使用 IN 子句和 regex_str 函数的存储过程。我不确定我应该如何进一步优化它?的主要内容,如果未能解决你的问题,请参考以下文章

带有 IN 子句的 SQL 查询的 MYSQL 查询优化

优化广泛使用 IN 子句的 Oracle SQL 查询

sql优化

删除“NOT IN”子句并优化查询

慢查询问题常见的优化方法

Postgresql - 超过 3000 个值的 IN 子句优化