|
|
|
Можно ли обойтись без составного индекса?
|
|||
|---|---|---|---|
|
#18+
Много текста, налейте чаю )) Отдельные запросы по members и d_p выполняются быстро (первые 2), но стоит их хоть как-то объединить и всё печально. Да можно добавить составной индекс members + d_p и я добавил его (последний запрос) результат хороший, но у меня около 10 запросов где используется members + ещё какое-то поле если на них все создавать по составному индексу то это накладно по месту не говоря уж о том что они будут намного больше доступной оперативной памяти. 0.0051 сек. (8800 строк) Код: sql 1. 0.0054 сек. Код: sql 1. 1.18 сек. используется индекс d_p Код: sql 1. Заменим принудительно индекс с d_p на members 2.88 сек. Код: sql 1. Используем подзапрос: 2.94 сек. Код: sql 1. Создадим, применим новый составной индекс 0.062 Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2016, 07:31 |
|
||
|
Можно ли обойтись без составного индекса?
|
|||
|---|---|---|---|
|
#18+
Применение составного индекса обеспечивает ускорение только за счёт того, что сканируется компактный индекс, а не пухлая таблица. Ну и за счёт того, что индекс кэшится эффективнее таблицы. Совсем уж разумно сделать его покрывающим - по (members, d_p, id). Без составного индекса можно рассмотреть только вариант подзапроса: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. При этом будет работать индекс, соответствующий условию 1. Но это имеет смысл только если селективность такого подзапроса высока (вернее, если количество отбираемых им записей мало). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2016, 10:33 |
|
||
|
Можно ли обойтись без составного индекса?
|
|||
|---|---|---|---|
|
#18+
Так я вот сделал с подзапросом и вроде так же как вы написали, но работает всё равно медленно, неудовлетворительно. Ещё вопрос тогда в тему: если заменить 2 одинарных индекса members и d_p одним составным members+d_p насколько хуже по нему будет искаться запрос только с одним условием? Например WHERE members > 1000 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2016, 12:19 |
|
||
|
Можно ли обойтись без составного индекса?
|
|||
|---|---|---|---|
|
#18+
попробуйте создать один составной индекс поле1+п2+п3+п4 такой составной будет использоваться как при запросаъ п1+п2, так и п1+п3 и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2016, 12:23 |
|
||
|
Можно ли обойтись без составного индекса?
|
|||
|---|---|---|---|
|
#18+
alfakukработает всё равно медленноЕсссно. alfakukесли заменить 2 одинарных индекса members и d_p одним составным members+d_p насколько хуже по нему будет искаться запрос только с одним условием? Например WHERE members > 1000Если таблица сравнительно невелика - для этого условия отбора пофиг. Если же индекс вымывается из кэша, то компактный по одному полю индекс эффективнее. А для условия отбора по d_p он скорее всего вообще не будет использоваться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2016, 12:26 |
|
||
|
Можно ли обойтись без составного индекса?
|
|||
|---|---|---|---|
|
#18+
авторпопробуйте создать один составной индекс поле1+п2+п3+п4 Мне тогда на 10 составной надо )) К тому же у меня запрашивается именно members+1, members+2, members+3 а 2+3 например никогда не запрашивается... авторЕсли таблица сравнительно невелика 6 млн. записей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2016, 15:51 |
|
||
|
Можно ли обойтись без составного индекса?
|
|||
|---|---|---|---|
|
#18+
alfakukу меня запрашивается именно members+1, members+2, members+3 а 2+3 например никогда не запрашивается...Ну вообще-то у тебя условия - неравенство, так что "всё сложно"... Если это основной поток запросов, то подумай про EAV. И - какова селективность отбора по members? alfakuk6 млн. записейА размер записи-то какой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2016, 15:57 |
|
||
|
Можно ли обойтись без составного индекса?
|
|||
|---|---|---|---|
|
#18+
AkinaПрименение составного индекса обеспечивает ускорение только за счёт того, что сканируется компактный индекс, а не пухлая таблица. Ну и за счёт того, что индекс кэшится эффективнее таблицы. Совсем уж разумно сделать его покрывающим - по (members, d_p, id). Без составного индекса можно рассмотреть только вариант подзапроса: Akina прав на все 100%. У тебя, дорогой ТС, почти все запросы неоптимизируемы индексом. Так что смысла создавать составные индексы нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2016, 16:35 |
|
||
|
Можно ли обойтись без составного индекса?
|
|||
|---|---|---|---|
|
#18+
автору тебя условия - неравенство, так что "всё сложно" Ну оно конкретно в этом запросе авторподумай про EAV Что такое EAV? авторкакова селективность отбора по members? Так себе..., из 6 млн. 90 тыс. уникальных записей авторА размер записи-то какой? Что такое размер записи можно уточнить? Количество столбцов в ней или тип поля или ещё что-то? авторТак что смысла создавать составные индексы нет Не понял почему смысла нет, как раз составной-то индекс показал хорошую работу, другое дело что их много надо и вставка и update за замедлятся ли при таком количестве? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2016, 17:00 |
|
||
|
Можно ли обойтись без составного индекса?
|
|||
|---|---|---|---|
|
#18+
alfakukНу оно конкретно в этом запросеВот какой смысл просить советов по оптимизации запроса, выполняющегося раз в месяц? alfakukиз 6 млн. 90 тыс. уникальных записей Т.е. Код: sql 1. 2. даёт порядка 90к? для строгих условий по members индекса по одному этому полю более чем достаточно (за исключением покрывающих индексов). alfakukЧто такое размер записи можно уточнить? INFORMATION_SCHEMA.TABLES Rows, Avg_row_length и Data_length alfakukЧто такое EAV? EAV ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2016, 17:22 |
|
||
|
Можно ли обойтись без составного индекса?
|
|||
|---|---|---|---|
|
#18+
авторINFORMATION_SCHEMA.TABLES Rows, Avg_row_length и Data_length Извините я чё-то не догнал, там дофига данных https://pp.vk.me/c636221/v636221960/24641/Adunhb4Sb-s.jpg непонятно совершенно какие для какой таблицы )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2016, 18:01 |
|
||
|
|

start [/forum/topic.php?fid=47&fpage=93&tid=1831429]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
45ms |
get topic data: |
5ms |
get forum data: |
1ms |
get page messages: |
25ms |
get tp. blocked users: |
1ms |
| others: | 197ms |
| total: | 292ms |

| 0 / 0 |
