ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Индексы
11 сообщений из 11, страница 1 из 1
Индексы
    #39312331
or12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
or12
Гость
Здравствуйте!

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

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

wurduТакдже не понятно откуда 5% взялись при условии что легко привести пример когда индексный доступ к 0.1% будет не эффективным по сравнению с fullscan.
Именно!
Единственно правильное решение - это смотреть на распределение данных в таблице. Вот к чему я клоню.
Кстати, также легко привести пример, когда получение 10% данных через индекс будет эффективнее fullscan.
Так что только or12 опытным путем
...
Рейтинг: 0 / 0
21.09.2016, 14:57
| Ответить | Цитировать | Написать  
Индексы
    #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
23.09.2016, 23:53
| Ответить | Цитировать | Написать  
11 сообщений из 11, страница 1 из 1
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Индексы
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=52&msg=39312410&tid=1887394]:
 0ms
get settings:
 6ms
get forum list:
 11ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 179ms
get topic data:
 6ms
get forum data:
 2ms
get page messages:
 28ms
get tp. blocked users:
 1ms
others: 203ms
total:  440ms
созд. / загр.: 440ms
x
x
Закрыть


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