Here we must correct a lot of online tutorials say fuzzy match can not take the index of the argument, because looking at the "harvest, more than SQL optimization," a book, which, for example when it comes up, and he is followed by examples of the practice of it, and indeed like some special cases also you can take the index of
Examples from the "harvest, more than SQL optimization," a book, practice preparation:
//建表，注意要非空数据
drop table t purge;
create table t as select * from dba_objects where object_id is not null;
select * from t;
//更新数据并建索引，用来测试
update t set object_id=rownum;
update t set object_name='AAALJB' where object_id=8;
update t set object_name='LJBAAA' where object_id=10;
create index idx_object_name on t(object_name);
used to print on a set autotrace implementation plan, pay attention here, with LJB% to fuzzy matching, and then observe the implementation plan, we found to be an index range scan INDEX RANGE SCAN, since the beginning of LJB to match the data, the index can range queries and to match, so the index scan range is able to walk, so to say the internet is not comprehensive
SQL> set autotrace on
SQL> select object_id,object_name from t where object_name like 'LJB%';
OBJECT_ID
----------
OBJECT_NAME
--------------------------------------------------------------------------------
10
LJBAAA
执行计划
----------------------------------------------------------
Plan hash value: 1138138579
--------------------------------------------------------------------------------
---------------
| Id | Operation | Name | Rows | Bytes | Cost (%C
PU)| Time |
--------------------------------------------------------------------------------
---------------
| 0 | SELECT STATEMENT | | 1 | 79 | 4
(0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| T | 1 | 79 | 4
(0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | IDX_OBJECT_NAME | 1 | | 3
(0)| 00:00:01 |
--------------------------------------------------------------------------------
---------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("OBJECT_NAME" LIKE 'LJB%')
filter("OBJECT_NAME" LIKE 'LJB%')
Note
-----
- dynamic sampling used for this statement (level=2)
SQL>
The above cited example of the index can go, then change it to match with% LJB, see if you can take the index?
SQL> set autotrace on
SQL> select object_id,object_name from t where object_name like '%LJB';
OBJECT_ID
----------
OBJECT_NAME
--------------------------------------------------------------------------------
8
AAALJB
执行计划
----------------------------------------------------------
Plan hash value: 1601196873
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 12 | 948 | 288 (1)| 00:00:04 |
|* 1 | TABLE ACCESS FULL| T | 12 | 948 | 288 (1)| 00:00:04 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("OBJECT_NAME" IS NOT NULL AND "OBJECT_NAME" LIKE '%LJB')
Note
-----
- dynamic sampling used for this statement (level=2)
统计信息
----------------------------------------------------------
0 recursive calls
0 db block gets
1032 consistent gets
0 physical reads
0 redo size
503 bytes sent via SQL*Net to client
419 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL>
Examples can be seen that a full table scan, the index does not go as% LJB this matching, index uniqueness can not be confirmed, the same% LJB% match is not going to take the index