Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Индексы / 11 сообщений из 11, страница 1 из 1
21.09.2016, 00:36:34
    #39312331
or12
or12
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Индексы
Здравствуйте!

предположим планируется создать индекс из 2-х полей, - одно с высокой селективностью, другое - с низкой. С одной стороны, на первое место нужно ставить поле с высокой селективностью. С другой - ставить на первое место с низкой, с целью компрессии ключа + для потенциального skip scan-а. Запросы могут быть как к первому полю, так и ко второму, или к обоим.

Существуют ли какие-то рекомендации, или только опытным путем?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.09.2016, 00:57:32
    #39312333
1+2
1+2
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Индексы
or12Запросы могут быть как к первому полю, так и ко второмуСделай два первых поля.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.09.2016, 06:15:29
    #39312347
wurdu
wurdu
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Индексы
Для запроса по 2-м полям порядок полей в индексе не важен. Для запроса по селективному полю логично иметь селективное поле 1-м в индексе, чтобы избежать INDEX SKIP SCAN. Запрос по не селективному полю индекс не будет использовать, соответственно не понятно зачем его хотеть ставить 1-м в индекс. Также возможно лучше вообще убрать не селективное поле из индекса, если скорость выборки только по селективному полю достаточна.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.09.2016, 06:34:42
    #39312349
Добрый Э - Эх
Добрый Э - Эх
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Индексы
wurduЗапрос по не селективному полю индекс не будет использовать, соответственно не понятно зачем его хотеть ставить 1-м в индекс.
для компрессии же:or12ставить на первое место с низкой, с целью компрессии ключа
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.09.2016, 09:19:57
    #39312410
AlexFF__|
AlexFF__|
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Индексы
wurduДля запроса по 2-м полям порядок полей в индексе не важен. Для запроса по селективному полю логично иметь селективное поле 1-м в индексе, чтобы избежать INDEX SKIP SCAN. Запрос по не селективному полю индекс не будет использовать, соответственно не понятно зачем его хотеть ставить 1-м в индекс. Также возможно лучше вообще убрать не селективное поле из индекса, если скорость выборки только по селективному полю достаточна.
Ну зачем сразу так категорично. "Зачем пациенту таблетки, давайте отрежем".
Например, если взять первый столбец с низкой селективностью из 10 значений и положить, что по обоим полям индексируется 5% таблицы, поставить его первым, то и сканирование по первому значению и по обоим и ISS по второму будет вполне замечательным.
or12Существуют ли какие-то рекомендации, или только опытным путем?
Рекомендации дали, но опытный путь всегда лучше )
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.09.2016, 09:36:21
    #39312434
or12
or12
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Индексы
Спасибо за ответы.
Не понял только ответ от 1+2
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.09.2016, 10:41:20
    #39312510
andrey_anonymous
andrey_anonymous
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Индексы
Добрый Э - Эхдля компрессии же
compress advanced low - и можно не париться на тему порядка полей "для компрессии".
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.09.2016, 13:41:43
    #39312675
or12
or12
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Индексы
andrey_anonymousДобрый Э - Эхдля компрессии же
compress advanced low - и можно не париться на тему порядка полей "для компрессии".
Спасибо, интересно.
"Ограничения": 12с + Advanced Compression Option.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.09.2016, 14:01:04
    #39312692
wurdu
wurdu
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Индексы
AlexFF__|wurduДля запроса по 2-м полям порядок полей в индексе не важен. Для запроса по селективному полю логично иметь селективное поле 1-м в индексе, чтобы избежать INDEX SKIP SCAN. Запрос по не селективному полю индекс не будет использовать, соответственно не понятно зачем его хотеть ставить 1-м в индекс. Также возможно лучше вообще убрать не селективное поле из индекса, если скорость выборки только по селективному полю достаточна.
Ну зачем сразу так категорично. "Зачем пациенту таблетки, давайте отрежем".
Например, если взять первый столбец с низкой селективностью из 10 значений и положить, что по обоим полям индексируется 5% таблицы, поставить его первым, то и сканирование по первому значению и по обоим и ISS по второму будет вполне замечательным.
Не понял. Каким это образом сканирование по колонке с низкой селективностью из 10-ти уникальных значений будет вдруг замечательным. Это должно быть очень специфичное распределение данных, к примеру какое-нить крайне неравномерное распределение с селективным значением чтобы индекс мог использоваться. В приведенном примере такой индекс не будет использоваться для поиска по первому не селективному значению. Также автор сказал что второе значение все-таки селективное, а не комбинация из 2-х неселективных полей. Такдже не понятно откуда 5% взялись при условии что легко привести пример когда индексный доступ к 0.1% будет не эффективным по сравнению с fullscan.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.09.2016, 14:57:06
    #39312744
AlexFF__|
AlexFF__|
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Индексы
wurduНе понял. Каким это образом сканирование по колонке с низкой селективностью из 10-ти уникальных значений будет вдруг замечательным. Это должно быть очень специфичное распределение данных, к примеру какое-нить крайне неравномерное распределение с селективным значением чтобы индекс мог использоваться. В приведенном примере такой индекс не будет использоваться для поиска по первому не селективному значению
Не нужно тут особо специальное распределение, пойдет и равномерное из 10 значений + 95% от всех записей в таблице NULL.
И индекс на 0.5% (1 из 10 на 5%) просто полетит.

wurduТакдже не понятно откуда 5% взялись при условии что легко привести пример когда индексный доступ к 0.1% будет не эффективным по сравнению с fullscan.
Именно!
Единственно правильное решение - это смотреть на распределение данных в таблице. Вот к чему я клоню.
Кстати, также легко привести пример, когда получение 10% данных через индекс будет эффективнее fullscan.
Так что только or12 опытным путем
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.09.2016, 23:53:54
    #39314699
pihel
pihel
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Индексы
andrey_anonymouscompress advanced low - и можно не париться на тему порядка полей "для компрессии".

Парится о порядке все же надо. Не надо будет париться только об числе столбцов для компрессии. Но об этом было и раньше просто узнать через analyze.
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
drop table t$t purge;
  
create table t$t as select 1 c1, round( dbms_random.VALUE(1, 10)) c2, level as c3
from dual connect by level < 1000000;
  
create index idx_t$t_0      on t$t(c1, c2, c3, 1);
create index idx_t$t_1      on t$t(c1, c2, c3, 2)  COMPRESS 1;
create index idx_t$t_2      on t$t(c1, c2, c3, 3)  COMPRESS 2;
create index idx_t$t_low    on t$t(c1, c2, c3, 4)  COMPRESS ADVANCED LOW;
create index idx_t$t_c3_low on t$t(c3, c1, c2, 5)  COMPRESS ADVANCED LOW;

 
select segment_type, segment_name, bytes, blocks from SYS.USER_SEGMENTS where segment_name like '%T$T%';

SEGMENT_TYPE       SEGMENT_NAME             BYTES     BLOCKS
------------------ ----------------------- ---------- ----------
TABLE              T$T                      18874368       2304
INDEX              IDX_T$T_0                29360128       3584
INDEX              IDX_T$T_1                26214400       3200
INDEX              IDX_T$T_2                23068672       2816
INDEX              IDX_T$T_LOW              23068672       2816
INDEX              IDX_T$T_C3_LOW           29360128       3584

 6 rows selected
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Индексы / 11 сообщений из 11, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 480ms
Закрыть
start [/forum/topic.php?fid=52&tablet=1&tid=1887394]:
 0ms
get settings:
 8ms
get forum list:
 15ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 185ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 43ms
get tp. blocked users:
 1ms
others: 211ms
total:  480ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]