|
|
|
Таблица для хранения Nested Sets - почему рекомендуют составной индекс?
|
|||
|---|---|---|---|
|
#18+
Есть некая таблица, которая используется для хранения структуры дерева Nested Sets. Соответственно, в ней есть поля "левый_ключ", "правый_ключ" и "уровень". И вот во всех материалах, что мне попадались по Nested Sets, всегда на подобные таблицы устанавливается составной индекс (левый_ключ, правый_ключ, уровень). Иногда с пояснением, что так надо для быстродействия, чаще это момент вообще никак не комментируется. Насколько я понимаю, составные индексы работают следующим образом. Все строки таблицы располагаются в порядке возрастания значений столбца, указанного в индексе первым. Строки с одинаковым значением первого столбца сортируются по значениям второго столбца. С одинаковым первым и вторым - по значениям третьего ну и т.д. То есть, если значения в первом столбце индекса уникальны, то в следующих столбцах в индексе просто нет смысла, зачем сортировать одну строку в пределах самой себя. Возвращаемся к Nested Sets. И видим, что значения в столбце "левый_ключ" у нас уникальны. Так зачем делают составной индекс? Что я упускаю из виду или понимаю неправильно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2012, 10:51 |
|
||
|
Таблица для хранения Nested Sets - почему рекомендуют составной индекс?
|
|||
|---|---|---|---|
|
#18+
Kenworth, Если все поля, на которые наложены условия выборки, входят в индекс - выборка происходит быстрее, поскольку серверу при поиске не приходится читать саму таблицу, только индекс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2012, 12:31 |
|
||
|
Таблица для хранения Nested Sets - почему рекомендуют составной индекс?
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинЕсли все поля, на которые наложены условия выборки, входят в индекс - выборка происходит быстрее, поскольку серверу при поиске не приходится читать саму таблицу, только индекс. Понял, спасибо за объяснение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2012, 13:59 |
|
||
|
Таблица для хранения Nested Sets - почему рекомендуют составной индекс?
|
|||
|---|---|---|---|
|
#18+
Kenworth, Это не совсем так. Например, в PostgreSQL < 9-х версий Index Only Scan просто отсутствует (и таблица всегда читается), в MS SQL индекс можно сделать кластерным, и тогда дополнительного чтения таблицы и не нужно. Зачем так надо для быстродействия, сходу не понятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2012, 21:35 |
|
||
|
Таблица для хранения Nested Sets - почему рекомендуют составной индекс?
|
|||
|---|---|---|---|
|
#18+
Kenworth, Это имеет смысл, потому что любой джойн, любой движок БД "рано или поздно" переколбасит в обыкновенный "вложенный цикл" перебора записей (не забываем про банальный Ассемблер в самом низу)... таблицы или индекса... так вот, в ряде случаев, сортировка составного индекса - ускоряет просмотры таких вложенных циклов на порядки, потому что составной, сортированный индекс - гарантирует, что запись не будет пропущена при дихотомическом спуске по индексу... не знаю, как по-другому объяснить, но составные индексы - это не просто "три отдельных поля"... это почти "муж и жена"... :) В Мускуле, используя переменные и составные индексы можно практически вручную управлять этим процессом перебора записей, и зная логику, ускорять выборки на порядки... но индивидуально к задаче... (из раздела "так делать не надо") :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2012, 07:03 |
|
||
|
Таблица для хранения Nested Sets - почему рекомендуют составной индекс?
|
|||
|---|---|---|---|
|
#18+
Arhat109любой джойн, любой движок БД "рано или поздно" переколбасит в обыкновенный "вложенный цикл" перебора записей Да шаззз... А как же MERGE JOIN и HASH JOIN?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2012, 12:45 |
|
||
|
Таблица для хранения Nested Sets - почему рекомендуют составной индекс?
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov, Что такое "щазззз"? Учите матчасть :), вот выписка из википедии (самому лениво): Это про merge join: Алгоритм соединения слиянием сортированных списков (merge join, sort merge join, sort-merge join) — разновидность алгоритма соединения. Алгоритм получает на вход 2 таблицы и условие соединения. Результатом его работы является таблица с результатами соединения. Входные таблицы должны быть отсортированы по столбцам , участвующим в условии соединения. Соединение осуществляется за одно сканирование (проход по) каждой из входных таблиц ( читай цикл, невложенный, потому что данные сортированы, о чём и написал, перечитайте внимательнее со слов "так вот..." ). То есть одна и та же строка считывается только один раз, что даёт преимущество перед соединением вложенными циклами... ... Главным недостатком алгоритма является необходимость в предварительной сортировке списков. Накладные расходы на сортировку могут быть неприемлемо высокими. При реализации в СУБД, соединение слиянием требует больше памяти и менее гибко, чем алгоритм соединения вложенными циклами.Многие авторы, в связи с этим, на практике рекомендуют избегать этого вида соединения. Во многих СУБД соединение слиянием по умолчанию не используется оптимизатором запросов и должно быть включено явно. Далее про хеш-джойн: Алгоритм соединения хэшированием (hash join) разновидность алгоритма соединения. Алгоритм получает на вход 2 таблицы и условие соединения. Результатом его работы является таблица с результатами соединения. Меньшая из двух входных таблиц помещается в специальную структуру данных в памяти: хэш-таблицу, которая обеспечивает очень высокую скорость поиска ( примечание - тоже самое и тут верно ). Затем для каждой строки из большей таблицы выполняется поиск значений, соответствующих условию соединения. Результаты помещаются в выходную таблицу. ... Недостатки: Условием соединения может быть только равенство. ... и эт-та, вопрос "об чём" был? О составном индексе... вот именно он и даёт ту самую сортировку ещё на стадии "вставки записи" ( понятно что за счет удлиненния времени вставки ), что и позволяет использовать "продвинутые методы", об чём и написал, вроде как. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2012, 16:57 |
|
||
|
Таблица для хранения Nested Sets - почему рекомендуют составной индекс?
|
|||
|---|---|---|---|
|
#18+
Arhat109эт-та, вопрос "об чём" был? О составном индексе... вот именно он и даёт ту самую сортировку ещё на стадии "вставки записи" Вопрос был "назачем он составной". А "сортировку на стадии записи" он даёт только если он кластерный или в случае IOT. Нормальные индексы данные не упорядочивают. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2012, 17:21 |
|
||
|
Таблица для хранения Nested Sets - почему рекомендуют составной индекс?
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov, "на стадии записи" - это зрятраты на создание самого индексу... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2012, 18:07 |
|
||
|
Таблица для хранения Nested Sets - почему рекомендуют составной индекс?
|
|||
|---|---|---|---|
|
#18+
Arhat109, дополню: мне, и думаю не только мне, в целом "по-бабрабану" как там лежат сами данные. Индекс, в т.ч. и составной - таки упорядочен. И, если я знаю что выборка по упорядоченному составному индексу идет значительно быстрее, то в ряде отдельно взятых случаев (из разряда не надо так делать, но приходится) могу выжать ту производительность из запроса, которую мне другим способом не получить ну никак... вон тут совсем недавно, чел мучался: миллионная табличка ищет записи по 40 секунд... или чуть пораньше: как избежать неограниченно вложенных джойнов в деревьях на одном parent_id... легко. Посмотрите фак по деревьям в разделе Мускуля и дату моего первого поста про один запрос и без джойнов... ваще без. Простой скан индекса. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2012, 18:13 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=38094735&tid=1541418]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
41ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
39ms |
get tp. blocked users: |
1ms |
| others: | 232ms |
| total: | 348ms |

| 0 / 0 |
