Индекс столбца, не отраженный в Плане объяснения для предикатов с оператором «IN» - PullRequest
0 голосов
/ 20 ноября 2018

У меня есть таблица с именем столбца IDENTIFIER , и таблица ( TAB1 ) имеет индекс для этого столбца.всякий раз, когда я пытаюсь запросить отдельные данные, используя простое предложение where с одним значением, план объяснения показывает, что он использует существующий индекс для этого конкретного столбца.

Но всякий раз, когда у меня есть список значений в другой таблице,скажем, временная таблица ( TEMP_IDENTIFIER ) со списком всех идентификаторов, которые я хочу запросить, и когда я формирую запрос к той же таблице с помощью IN предложения , я вижу этот план объясненияне рассматривает индекс, вместо этого он выполняет полное сканирование таблицы

В идеале я хотел бы, чтобы второй запрос также использовал существующий индекс

Пожалуйста, найдите оба запроса и объяснитепланировать следующим образом


Запрос 1

explain plan for
select * from schemaowner.TAB1 
where IDENTIFIER = 'A'; 

Объяснить план

Plan hash value: 4172144893

------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name             | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                  |    51 | 12750 |    11   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| TAB1             |    51 | 12750 |    11   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | COL_INDEX        |    51 |       |     4   (0)| 00:00:01 |
------------------------------------------------------------------------------------------------

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

   2 - access("IDENTIFIER"='A')

Запрос 2

explain plan for
select * from schemaowner.TAB1 
where IDENTIFIER in (select IDENTIFIER from SCHEMAOWNER.temp_IDENTIFIER);

План объяснения:

Plan hash value: 935676029

-------------------------------------------------------------------------------------------------
| Id  | Operation            | Name             | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |                  |  3135K|   822M|       | 74751   (1)| 00:14:58 |
|*  1 |  HASH JOIN RIGHT SEMI|                  |  3135K|   822M|  2216K| 74751   (1)| 00:14:58 |
|   2 |   TABLE ACCESS FULL  | TEMP_IDENTIFIER  | 61115 |  1492K|       |    85   (2)| 00:00:02 |
|   3 |   TABLE ACCESS FULL  | TAB1             |  3745K|   893M|       | 28028   (2)| 00:05:37 |
-------------------------------------------------------------------------------------------------

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

   1 - access("IDENTIFIER"="IDENTIFIER")

Note
-----
   - dynamic sampling used for this statement (level=2)

1 Ответ

0 голосов
/ 21 ноября 2018

В этом вся прелесть оптимизатора.Выяснилось (или стоило), что соединение SEMI является наиболее эффективным методом:)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...