2. 程式人生 > >oracle like模糊查詢的優化測試

oracle like模糊查詢的優化測試

阿新 • • 發佈：2019-02-02

三種like模糊查詢的優化：
第一種：like 'a%'這種，直接可走索引
第二種：like '%a'這種，需要用reverse反轉函式改寫SQL，再建立函式索引，如下：
  改寫前:
   select * from test where owner like '%SCOTT'
   改寫後：
   select * from test where reverse(owner) like reverse('%SCOTT');
第三種：like '%a%'這種的優化，進行如下測試：

原SQL:
SELECT A0.*
 FROM g.wp A0
 where A0.ptc_str_12TYPEINFOWABCDT like '%中ABCDdddddddd機%';

OS下執行：
export NLS_LANG=AMERICAN_AMERICA.utf8

SQL> set line 1000
SQL> set pagesize 1000
SQL> set autotrace traceonly
SQL> set timing on
SQL> SELECT A0.*
  2   FROM g.wp A0
  3   where A0.ptc_str_12TYPEINFOWABCDT like '%中ABCDdddddddd機%';

4694 rows selected.

Elapsed: 00:03:47.72

Execution Plan
----------------------------------------------------------
Plan hash value: 1382574215

----------------------------------------------------------------------------
| Id  | Operation         | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |        |   348K|   330M|   323K  (1)| 01:04:46 |
|*  1 |  TABLE ACCESS FULL| WABCDT |   348K|   330M|   323K  (1)| 01:04:46 |
----------------------------------------------------------------------------

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

   1 - filter("A0"."PTC_STR_12TYPEINFOWABCDT" IS NOT NULL AND
              "A0"."PTC_STR_12TYPEINFOWABCDT" LIKE '%中ABCDdddddddd機%')


Statistics
----------------------------------------------------------
         29  recursive calls
          0  db block gets
    1292784  consistent gets
      39729  physical reads
          0  redo size
    3087832  bytes sent via SQL*Net to client
      52158  bytes received via SQL*Net from client
       4696  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
       4694  rows processed
為了降低從磁碟中讀取資料對查詢時間的影響 ，再執行第二次：

SQL> SELECT A0.*
  2   FROM g.wp A0
  3   where A0.ptc_str_12TYPEINFOWABCDT like '%中ABCDdddddddd機%';

4694 rows selected.

Elapsed: 00:00:33.84
Execution Plan
----------------------------------------------------------
Plan hash value: 1382574215

----------------------------------------------------------------------------
| Id  | Operation         | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |        |   348K|   330M|   323K  (1)| 01:04:46 |
|*  1 |  TABLE ACCESS FULL| WABCDT |   348K|   330M|   323K  (1)| 01:04:46 |
----------------------------------------------------------------------------

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

   1 - filter("A0"."PTC_STR_12TYPEINFOWABCDT" IS NOT NULL AND
              "A0"."PTC_STR_12TYPEINFOWABCDT" LIKE '%中ABCDdddddddd機%')


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
    1292776  consistent gets
          0  physical reads
          0  redo size
    3087832  bytes sent via SQL*Net to client
      52158  bytes received via SQL*Net from client
       4696  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
       4694  rows processed


改寫SQL:

SELECT A0.*
 FROM g.wp A0
 where instr(A0.ptc_str_12TYPEINFOWABCDT,'中ABCDdddddddd機')>0;

SQL> SELECT A0.*
  2   FROM g.wp A0
  3   where instr(A0.ptc_str_12TYPEINFOWABCDT,'中ABCDdddddddd機')>0;

4694 rows selected.

Elapsed: 00:03:36.91

Execution Plan
----------------------------------------------------------
Plan hash value: 1382574215

----------------------------------------------------------------------------
| Id  | Operation         | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |        |   434K|   412M|   323K  (1)| 01:04:46 |
|*  1 |  TABLE ACCESS FULL| WABCDT |   434K|   412M|   323K  (1)| 01:04:46 |
----------------------------------------------------------------------------

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

   1 - filter(INSTR("A0"."PTC_STR_12TYPEINFOWABCDT",'中ABCDdddddddd機')>0)


Statistics
----------------------------------------------------------
         29  recursive calls
          0  db block gets
    1292793  consistent gets
      39727  physical reads
          0  redo size
    3087832  bytes sent via SQL*Net to client
      52158  bytes received via SQL*Net from client
       4696  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
       4694  rows processed

建立函式索引：
create  index g.fx_WABCDT_1 on g.wp(instr(ptc_str_12TYPEINFOWABCDT,'中ABCDdddddddd機')) tablespace gx parallel 16;
alter index g.fx_WABCDT_1 noparallel;


SQL> SELECT A0.*
  2   FROM g.wp A0
  3   where instr(A0.ptc_str_12TYPEINFOWABCDT,'中ABCDdddddddd機')>0;

4694 rows selected.

Elapsed: 00:00:02.31

Execution Plan
----------------------------------------------------------
Plan hash value: 3331311615

-------------------------------------------------------------------------------------------
| Id  | Operation                   | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |             |   434K|   412M| 12577   (1)| 00:02:31 |
|   1 |  TABLE ACCESS BY INDEX ROWID| WABCDT      |   434K|   412M| 12577   (1)| 00:02:31 |
|*  2 |   INDEX RANGE SCAN          | FX_WABCDT_1 | 78135 |       |   145   (1)| 00:00:02 |
-------------------------------------------------------------------------------------------

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

   2 - access(INSTR("PTC_STR_12TYPEINFOWABCDT",'中ABCDdddddddd機')>0)


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       9603  consistent gets
          0  physical reads
          0  redo size
    3085926  bytes sent via SQL*Net to client
      52158  bytes received via SQL*Net from client
       4696  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
       4694  rows processed


邏輯讀從 1292776減少到9603，執行時間由33.84s降低到02.31s。但若用繫結變數的情況，不適合這種方法。

若用繫結變數的情況:
指定hint：
SELECT /*+index(A0 CLS_INDEX) */ A0.*
 FROM WABCDT A0
 where A0.ptc_str_12TYPEINFOWTPART like '中ABCDdddddddd機';
Elapsed: 00:00:05.00

Execution Plan
----------------------------------------------------------
Plan hash value: 4025305430

-----------------------------------------------------------------------------------------
| Id  | Operation                   | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |           |   348K|   330M|   141K  (1)| 00:28:20 |
|   1 |  TABLE ACCESS BY INDEX ROWID| WABCDT    |   348K|   330M|   141K  (1)| 00:28:20 |
|*  2 |   INDEX FULL SCAN           | CLS_INDEX |   356K|       | 44775   (1)| 00:08:58 |
-----------------------------------------------------------------------------------------

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

   2 - filter("A0"."PTC_STR_12TYPEINFOWTPART" IS NOT NULL AND
              "A0"."PTC_STR_12TYPEINFOWTPART" LIKE '中ABCDdddddddd機')


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
      55985  consistent gets
          0  physical reads
          0  redo size
    3085926  bytes sent via SQL*Net to client
      52158  bytes received via SQL*Net from client
       4696  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
       4694  rows processed

上面有用到index full scan，邏輯讀減少很多，由1292784減少到55985，若所有需要訪問的資料都在記憶體中，那麼執行比較快，上面執行時間為5秒，反之，若需要的資料從磁碟中讀取，是比較慢， 所以採用將索引和表的數全部keep到cache中。

先檢視db_keep_cache_size大小和索引及表的大小，若keep cache不足以存放表和索引，則需要調大引數。
SQL> show parameter keep

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
buffer_pool_keep                     string
control_file_record_keep_time        integer     7
db_keep_cache_size                   big integer 15G

SQL> col segment_name for a20;
SQL> select segment_name,segment_type,bytes/1024/1024 "size(MB)" from dba_segments where owner='G' and segment_name in ('WABCDT','CLS_INDEX');

SEGMENT_NAME         SEGMENT_TYPE         size(MB)
-------------------- ------------------ ----------
WABCDT               TABLE                   10075
CLS_INDEX            INDEX                     367

將索引和表keep到記憶體中：
alter index g.CLS_INDEX storage(buffer_pool keep);
alter table g.wtpart storage(buffer_pool keep);
alter table g.wtpart cache;


SQL> select index_name,buffer_pool from dba_indexes where index_name='CLS_INDEX';

INDEX_NAME                     BUFFER_
------------------------------ -------
CLS_INDEX                      KEEP

SQL> select owner,table_name,CACHE,BUFFER_POOL from dba_tables where table_name='WABCDT' and owner='G';

OWNER                          TABLE_NAME                     CACHE                BUFFER_
------------------------------ ------------------------------ -------------------- -------
G                           WABCDT                           Y                KEEP

上面顯示已有正確keep表和索引到cache中。這樣就可確保除第一次外，其它每次訪問的資料都能從記憶體中獲取。

看下count(*)的情況：

SQL> SELECT count(*)
  2   FROM WABCDT  A0
  3   where A0.ptc_str_12TYPEINFOWABCDT like '%中ABCDdddddddd機%';

Elapsed: 00:00:02.04

Execution Plan
----------------------------------------------------------
Plan hash value: 3203503055

-----------------------------------------------------------------------------------
| Id  | Operation             | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |           |     1 |    11 | 12209   (2)| 00:02:27 |
|   1 |  SORT AGGREGATE       |           |     1 |    11 |            |          |
|*  2 |   INDEX FAST FULL SCAN| CLS_INDEX |   348K|  3742K| 12209   (2)| 00:02:27 |
-----------------------------------------------------------------------------------

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

   2 - filter("A0"."PTC_STR_12TYPEINFOWABCDT" IS NOT NULL AND
              "A0"."PTC_STR_12TYPEINFOWABCDT" LIKE '%中ABCDdddddddd機%')


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
      46773  consistent gets
          0  physical reads
          0  redo size
        527  bytes sent via SQL*Net to client
        524  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

上面用了INDEX FAST FULL SCAN，走索引的地方是conut(*),並不是where條件。

相關推薦

oracle like模糊查詢的優化測試

三種like模糊查詢的優化： 第一種：like 'a%'這種，直接可走索引 第二種：like '%a'這種，需要用reverse反轉函式改寫SQL，再建立函式索引，如下：   改寫前:    select * from test where owner like '%SCO

oracle like模糊查詢簡單用法

簡單 rom 模糊 acl 用法 介紹 情況 文章 分享圖片 like 用法介紹： 1、“_”：匹配單個任意字符 select * from bqh3 where name like ‘_崔‘; 2、“%”：匹配0個或多個任意字符。但有三種情況如下：

mysql 優化 - like模糊查詢優化

在使用msyql進行模糊查詢的時候，很自然的會用到like語句，通常情況下，在資料量小的時候，不容易看出查詢的效率，但在資料量達到百萬級，千萬級的時候，查詢的效率就很容易顯現出來。這個時候查詢的效率就顯得很重要！ 一般情況下like模糊查詢的寫法為（field已建立索引）： SE

Oracle like模糊查詢-無效的列索引

1、當寫成like（'%?%'）時會提示無效的列索引 改成like('%'||?||'%')時可以解決 下面為轉載內容 java.sql.SQLException: 無效的列索引 “無效的列索引”其實是個低階的錯誤，原因無非幾個： 1、sql串的?號數目

oracle Like模糊查詢與帶有關鍵字Reverse的索引應用

在對oracle的SQL優化過程中經常會遇到【like'%abc'】破壞索引的問題，但是如果真有此類需求，該如何在不破壞索引的基礎上進行查詢呢。 上程式碼 [email protected]> select reverse('123') from dua

mysql中like模糊查詢的優化

這是我在一個百萬級資料庫資料匯出遇到的問題 比如這個語句在這個資料庫查詢很慢： select a from tms where b like ‘%haha%’ order by time limit 100; 第一種優化方法（注意：這種方法只適用於haha開頭的）: //將haha欄位和

Oracle大欄位（clob）模糊查詢優化方法

對於內容很多的時候clob打欄位模糊查詢很慢，整理一個小方法： 1，在查詢的列上建索引         2，對於要查詢的clob欄位使用一下語句建立索引   CREATE INDEX idx_zs_info_note ON zs_info(note) INDEXTYPE

Oracle中like模糊查詢及萬用字元

like 模糊查詢 我們只知道個別字母或者欄位，不太確定要查詢的準確資訊時，可以使用模糊查詢(即like)，查詢出所有與自己已知的"零碎"資訊有關的全部資訊。 這就要用的like模糊查詢了，其萬用字

.net like模糊查詢參數化

string sha parameter 錯誤 and 程序 報錯 sel csharp List<SqlParameter> paras = new List<SqlParameter>();

sql like模糊查詢的條件拼接

body con ted cond -c where sel apple b- 被坑了兩次,記錄加深記憶 oracle : select * from table_name where 1=1 <#if secondName?? &&

python中的mysql數據庫like模糊查詢

script art exec -m con python abc san exe 近期工作在使用python語言開發項目，工作中遇到了一個python連接mysq

記一次使用mybatis進行like 模糊查詢遇到的問題

bat 通過 模糊查詢 date 但是 AR 通配符 問題 解決辦法 "bdate like ‘#{date}%‘ and ..." 最開始這樣寫的· 將傳入的參數和%用單引號包起來，但是這會報錯 java.sql.SQLException: Parameter in

mybatis xml檔案中的大於、小於、及like模糊查詢的寫法

在xml中，特殊符號的轉義寫法如下： &lt; < &gt; > &lt;&gt; <> &amp; & &

mybaits LIKE 模糊查詢

1.  引數中直接加入%% 　　param.setUsername("%CD%");       param.setPassword("%11%"); <select id="selectPersons" resultTy

mybatis Example Criteria like 模糊查詢

用Mybatis程式碼生成工具會產生很多個XXXExample類，這些類的作用是什麼？ 查閱了很多資料，在這裡總結歸納一下 簡介 XXXExample類用於構造複雜的篩選條件 它包含一個名為Criteria的內部靜態類，它包含將在where子句中一起結合的條件列

mybatis做like模糊查詢

1.  引數中直接加入%% 　　param.setUsername("%CD%");       param.setPassword("%11%"); <select id="selectPersons" resultType="person" para

laravel原生sql操作以及like模糊查詢的坑點

此篇文章基於 laravel版本:5.5 laravel基於DB的原生查詢可以使用 DB facade 執行查詢。DB facade 為每種型別的查詢提供了方法：select、update、insert、delete 和 statement。以下是知識點: (1)執行

Oracle中模糊查詢中轉義用法

Oracle中模糊查詢中轉義的關鍵字是escape 具體用法如下 select * from DEPT_02_tmp a  where a.dname like 'IT/_%'escape'/'; escape後面接的是轉義識別符號  識別符號後面跟的是 需要轉義的內

mysql正則表示式，實現多個欄位匹配多個like模糊查詢

現在有這麼一個需求 一個questions表，欄位有題目(TestSubject)，選項(AnswerA，AnswerB，AnswerC，AnswerD,AnswerE) 要求欄位不包含png,jpg,jpeg,gif  正常情況下會這麼寫 select * from questions

MyBatis like (模糊查詢)

  select * from user where user_name like concat('%',#{userName},'%'); select * from user where user_name like concat(#{userName},'%'); select *