Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности

Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
01.11.2019, 11:53
|
|||
|---|---|---|---|
|
|||
Индекс и сортировка по двум полям |
|||
|
#18+
Всем привет. Есть запрос, который выполняется очень долго. Сам запрос: Код: sql 1. Его план Код: sql 1. 2. 3. 4. 5. 6. 7. id - первичный ключ по колонке logdate построен индекс. Я попробовал составные индексы между ними - толку 0. Он все равно смотрит всю таблицу. Там 20 млн. записей Подскажите, пожалуйста, как заставить запрос работать по индексам! Заранее спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
01.11.2019, 12:55
|
|||
|---|---|---|---|
|
|||
Индекс и сортировка по двум полям |
|||
|
#18+
_WeSTMan_Всем привет. Есть запрос, который выполняется очень долго. Сам запрос: Код: sql 1. Его план Код: sql 1. 2. 3. 4. 5. 6. 7. id - первичный ключ по колонке logdate построен индекс. Я попробовал составные индексы между ними - толку 0. Он все равно смотрит всю таблицу. Там 20 млн. записей Подскажите, пожалуйста, как заставить запрос работать по индексам! Заранее спасибо! 1)большие offset никак быстро работать не будут что с ними не делай... потому что всеравно надо перебрать limit+offset записей... т.е. запрос в общем случае эквивалентен limit 700000. 2)для такого order by нужен индекс (log_date DESC, id ASC) составной а вы небось просто делали (log_date, id) порядок сортировок в индексе должен совпадать с порядком сортировок в order by полностью. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
01.11.2019, 13:05
|
|||
|---|---|---|---|
Индекс и сортировка по двум полям |
|||
|
#18+
Maxim Boguk1)большие offset никак быстро работать не будут что с ними не делай... потому что всеравно надо перебрать limit+offset записей... т.е. запрос в общем случае эквивалентен limit 700000. 2)для такого order by нужен индекс (log_date DESC, id ASC) составной а вы небось просто делали (log_date, id) порядок сортировок в индексе должен совпадать с порядком сортировок в order by полностью. 1. 700000 << 18 000 000. но да, быстро не будет 2 ... или с полностью инвертированным по всем измерениям ... (if btree) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
01.11.2019, 13:17
|
|||
|---|---|---|---|
|
|||
Индекс и сортировка по двум полям |
|||
|
#18+
qwwq2 ... или с полностью инвертированным по всем измерениям ... (if btree) да полезное уточнение... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
01.11.2019, 14:01
|
|||
|---|---|---|---|
|
|||
Индекс и сортировка по двум полям |
|||
|
#18+
Maxim Boguk_WeSTMan_Всем привет. Есть запрос, который выполняется очень долго. Сам запрос: Код: sql 1. Его план Код: sql 1. 2. 3. 4. 5. 6. 7. id - первичный ключ по колонке logdate построен индекс. Я попробовал составные индексы между ними - толку 0. Он все равно смотрит всю таблицу. Там 20 млн. записей Подскажите, пожалуйста, как заставить запрос работать по индексам! Заранее спасибо! 1)большие offset никак быстро работать не будут что с ними не делай... потому что всеравно надо перебрать limit+offset записей... т.е. запрос в общем случае эквивалентен limit 700000. 2)для такого order by нужен индекс (log_date DESC, id ASC) составной а вы небось просто делали (log_date, id) порядок сортировок в индексе должен совпадать с порядком сортировок в order by полностью. Спасибо большое! Все работает!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=53&mobile=1&tid=1994969]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
92ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
| others: | 305ms |
| total: | 478ms |

| 0 / 0 |
