|
|
|
Индексы - вопрос с пониманием
|
|||
|---|---|---|---|
|
#18+
Объясните пожалуйста, какая принципиальная разница между одним индексом на два поля и двумя индексами на эти же поля (в одном и том же направлении)? все ЗА и ПРОТИВ? а то я недопонимаю и почему-то нигде не читал про это, хотя понимаю, что это не одно и тоже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.05.2008, 21:07 |
|
||
|
Индексы - вопрос с пониманием
|
|||
|---|---|---|---|
|
#18+
Alexey FurmanovОбъясните пожалуйста, какая принципиальная разница между одним индексом на два поля и двумя индексами на эти же поля (в одном и том же направлении)? все ЗА и ПРОТИВ? а то я недопонимаю и почему-то нигде не читал про это, хотя понимаю, что это не одно и тоже.Все pro и contra - это потянет, как минимум, на большую статью. Так что всегда лучше рассматривать конкретную ситуацию, а не общий случай. В первую очередь надо исходить из наиболее употребимых условий доступа к таблице. Если чаще всего идет доступ с условием по 2-м полям, то в индекс естественно лучше включить оба. Если в таком случае сделать 2 индекса, то поиск по ним обоим одновременно со слиянием результатов может оказаться значительно более дорогим для сервера, и он может попросту отказаться от использования обоих и будет использовать только один из них, обычно максимально селективный. Если же преобладает доступ с условием только по одному из полей, то мысль сделать 2 разных индекса может оказаться не такой уж и плохой. Правда тут нужно помнить, что обновлять 2 индекса после модификации данных требует от сервера несколько больших усилий, чем обновление одного. Кроме того, множество разных значений по одному из полей может оказаться настолько малым, что серверу будет дешевле просканировать таблицу, фильтруя результаты, чем сначала из индекса выбрать по условию огромное количество указателей на строки в таблице, а потом по ним шерстить еще и таблицу. Таким образом, индекс может оказаться абсолютно ненужным. В общем, это, так, навскидку. Повторюсь, лучше все-таки рассматривать конкретные ситуации и провести анализ типовых запросов к таблице, включая и ее слияние с другими таблицами. В этом случае, "правильный" индекс может дать особенно большой выигрыш. P.S. Кстати, для индексов на 2 поля не менее важно выбрать правильный порядок этих полей, чтобы при типовых условиях отбора значения были максимально близки друг к другу в физическом смысле, чтобы уменьшить количество физических операций I/O. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.05.2008, 22:42 |
|
||
|
Индексы - вопрос с пониманием
|
|||
|---|---|---|---|
|
#18+
Alexey Furmanov пишет: > Объясните пожалуйста, какая принципиальная разница между одним индексом > на два поля и двумя индексами на эти же поля (в одном и том же > направлении)? В основном разница в том, что при двух индексах по двум полям idx1(a), idx2(b) возможен быстрый поиск по каждому из этих полей. т.е. select * from thetable where a = xxx и select * from thetable where b = yyy могут работать быстро А при одном индексе idx1(a,b) возможен быстрый поиск только по a, select * from thetable where a = xxx ИЛИ по a и b одновременно. select * from thetable where a = xxx and b = yyy А вот по полю b в select * from thetable where b = yyy уже быстрый поиск невозможен. Так что это ВОВСЕ НЕ ОДНО И ТО ЖЕ. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2008, 01:50 |
|
||
|
Индексы - вопрос с пониманием
|
|||
|---|---|---|---|
|
#18+
В доке по MySQL есть глава How MySQL Uses Indexes Думаю, сказанное там могут большинство СУБД. MasterZiv А при одном индексе idx1(a,b) ... А вот по полю b в select * from thetable where b = yyy уже быстрый поиск невозможен.Помнится, насчет Index Skip Scans мы с вами уже дискутировали. Хотя, конечно, такая фича есть далеко не у всех СУБД и полезна она бывает нечасто. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2008, 13:57 |
|
||
|
Индексы - вопрос с пониманием
|
|||
|---|---|---|---|
|
#18+
Alexey FurmanovОбъясните пожалуйста, какая принципиальная разница между одним индексом на два поля и двумя индексами на эти же поля Примерно такая же, как между семьей с двумя детьми и двумя родителями-одиночками с ребенком каждый. Это просто разные вещи, ограниченно и до определенной степени способные заменить одна другую. Основная разница между ними проистекает из того факта, что "два индекса" - симметричные объекты. Если в запросе Вы поменяете поле1 на поле2, получите симметричный результат для другого индекса. В одном индексе порядок полей имеет значение, и результат, полученный для поля1 вовсе не обязательно повторится для поле2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2008, 16:36 |
|
||
|
Индексы - вопрос с пониманием
|
|||
|---|---|---|---|
|
#18+
всем спасибо за информацию, я пришёл для себя к таким выводам: 1) если не знать сути будущих запросов к проектируемой БД (а такое, имхо, бывает нередко), то предпочтительно использовать индексы на одно поле, это более универсально, хотя в сложных случаях - работает медленнее, 2) если же сразу знать суть выполняемых запросов (или выяснив это на этапе кодирования бизнес-логики), то имеет смысл оптимизировать индексы и в случае необходимости заменить два (или несколько) одиночных индекса на один двойной (составной), соблюдая порядок полей индексации в запросах 3) если какое-либо поле (группа полей), участвующее(-ие) в составном идексе, может использоваться для фильтрации в запросах без других полей из этого же индекса (автономно), то оно (они) должно(-ы) находиться в составном индексе на первом месте, 4) при этом стоит уменьшить количество индексов до необходимого минимума, каждый лишний индекс - это накладные расходы при вставке данных (ну и, наверное, при пересчёте статистики). 5) если количество записей в таблице небольшое (ну пусть будет до 100, но скорее всего это зависит от размера данных, размера страницы, размера страницы индексов и ещё кучи всяких парметров), то лучше вообще не прибегать к использованию индексов это верно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2008, 14:38 |
|
||
|
Индексы - вопрос с пониманием
|
|||
|---|---|---|---|
|
#18+
Alexey Furmanov1) если не знать сути будущих запросов к проектируемой БД (а такое, имхо, бывает нередко), то предпочтительно использовать индексы на одно поле, это более универсально, хотя в сложных случаях - работает медленнее, Если не знать сути будущих запросов к проектируемой БД, то индексов лучше вообще не делать (исключая обычный набор по PK/FK). Все прочее лучше отложить до того момента, когда ситуация прояснится. Alexey Furmanov5) если количество записей в таблице небольшое (ну пусть будет до 100, но скорее всего это зависит от размера данных, размера страницы, размера страницы индексов и ещё кучи всяких парметров), то лучше вообще не прибегать к использованию индексов Это в общем-то достаточно неоднозначный вопрос. Впрочем, можно сказать так: если количество записей в таблице "небольшое", то любое решение будет работать вполне приемлемо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2008, 15:26 |
|
||
|
Индексы - вопрос с пониманием
|
|||
|---|---|---|---|
|
#18+
Alexey Furmanov пишет: > 4) при этом стоит уменьшить количество индексов до необходимого > минимума, каждый лишний индекс - это накладные расходы при вставке > данных (ну и, наверное, при пересчёте статистики). И при изменении. Конечно только если изменения затрагивают проиндексированные поля. > это верно? Да, более-менее. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2008, 23:14 |
|
||
|
Индексы - вопрос с пониманием
|
|||
|---|---|---|---|
|
#18+
Еще добавлю к вышеприведенному: полезно знать архитектуру и особенности используемой СУБД. Т.к. в разных СУБД есть разные решения, которые могут существенно ускорить выполнение запросов. Особенно если данные извлекаются из нескольких таблиц. Например, для MS SQL очень ускоряет выборку правильный кластерный индекс + индекс по полю в другой таблице, а также по возможности отказ от использования в запросах пользовательских функций (не встроенных). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2008, 15:54 |
|
||
|
Индексы - вопрос с пониманием
|
|||
|---|---|---|---|
|
#18+
Yuriy YurchenkoНапример, для MS SQL очень ускоряет выборку правильный кластерный индекс... Юра, привет, рад тебя слышать, насколько помню, кластерный индекс может быть только один на таблицу и по умолчанию он включается на PRIMARY KEY, я люблю пользоваться суррогатными ключами, потому не совсем понятно, что ты подразумеваешь под словом ПРАВИЛЬНЫЙ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2008, 18:15 |
|
||
|
Индексы - вопрос с пониманием
|
|||
|---|---|---|---|
|
#18+
Alexey Furmanov...кластерный индекс ... по умолчанию он включается на PRIMARY KEY...умолчания несложно изменить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2008, 22:23 |
|
||
|
Индексы - вопрос с пониманием
|
|||
|---|---|---|---|
|
#18+
softwarerЕсли не знать сути будущих запросов к проектируемой БД, то индексов лучше вообще не делать (исключая обычный набор по PK/FK). Все прочее лучше отложить до того момента, когда ситуация прояснится. Да это точно, от лишних индексов в настроенной системе трудно будет избавиться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.05.2008, 20:14 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=35305077&tid=1543873]: |
0ms |
get settings: |
5ms |
get forum list: |
20ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
66ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
| others: | 238ms |
| total: | 389ms |

| 0 / 0 |
