Форум PHP программистов > MySql составной индекс для запросов вида IN

[ Поиск ] - [ Пользователи ] - [ Календарь ]

Полная Версия: MySql составной индекс для запросов вида IN

Страницы: 1, 2, 3

Valick

17.12.2015 - 13:23

Цитата (Serg86 @ 17.12.2015 - 12:06)

Как сказать запросу чтоб кеширование не использовал, чтобы реальную картину видеть?

пробел перед запросом

_____________
Стимулятор ~yoomoney - 41001303250491

S.Chushkin

17.12.2015 - 14:11

Цитата (Serg86 @ 17.12.2015 - 10:21)

Да я всю таблицу не стал сливать просто, если надо солью больше

Для оптимизации размер важен.

Цитата

Будет миллион, будет больше, это логично.

Относительно - да. Но не линейно.

Цитата

Составныеиндексы не работают почемуто, судя по explain задействуется только cat. Вчера похимичил посидел, удалось задействовать status_cat, время значительно снизилось.

Работают, просто нужен правильный индекс.

Цитата

Подскажите, можно с этим както бороться?

Правильный индекс тчк

Т.к. Вы не предоставили реальный дамп, поговорим о сферическом коне.
Для Вашего конкретного запроса оптимальным будет индекс:

KEY `idx` (`status`,`raised`,`date_add`,`cat`,`region`,`id`)

Для ещё большей оптимальности поправьте ORDER BY в запросе:

ORDER by d.status desc, d.raised desc, d.date_add desc

Теперь на 50К данных выборка первых 30 строк займёт порядка 0.005 сек.
Можно и дальше оптимизировать, но оптимальность запроса уже будет зависить от других параметров.

_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru

S.Chushkin

17.12.2015 - 14:13

Цитата (Serg86 @ 17.12.2015 - 10:25)

Через какоето время запускаю запрос снова и он выполняется за 15 секунд, тут же повторяю запрс и получаю 0,1 секунду, в чем прикол не пойму.

Это эффект чтения таблицы с диска в буфер. Повторное чтение - вероятно у Вас слишком маленький размер буфера (конкретно эти данные были вытеснены из него другими данными).
Все тесты надо проводить, когда все данные в буфере. Иначе Вы получите не скорость выполнения запроса, а скорость чтения с диска.

_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru

Serg86

17.12.2015 - 17:14

Цитата

Не совсем понял, буфер MySql?

Serg86

17.12.2015 - 17:16

Цитата

Т.к. Вы не предоставили реальный дамп, поговорим о сферическом коне.
Для Вашего конкретного запроса оптимальным будет индекс:
KEY `idx` (`status`,`raised`,`date_add`,`cat`,`region`,`id`)

Для ещё большей оптимальности поправьте ORDER BY в запросе:
ORDER by d.status desc, d.raised desc, d.date_add desc

Щас попробую, отпишусь.

S.Chushkin

17.12.2015 - 17:38

Цитата (Serg86 @ 17.12.2015 - 17:14)

Не совсем понял, буфер MySql?

Да

_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru

Serg86

17.12.2015 - 17:50

Цитата

Цитата
Т.к. Вы не предоставили реальный дамп, поговорим о сферическом коне.
Для Вашего конкретного запроса оптимальным будет индекс:
KEY `idx` (`status`,`raised`,`date_add`,`cat`,`region`,`id`)

Для ещё большей оптимальности поправьте ORDER BY в запросе:
ORDER by d.status desc, d.raised desc, d.date_add desc
Щас попробую, отпишусь.

Не прокатило
explain говорит key_len 5, rows 85700
Я так понял что только статус задействован

Serg86

17.12.2015 - 17:51

S.Chushkin Сможете в реальной базе глянуть? мож я че не так делаю, у меня ваших цифр и близко нет

Serg86

17.12.2015 - 18:19

Цитата

Цитата (Serg86 @ 17.12.2015 - 12:06)
Как сказать запросу чтоб кеширование не использовал, чтобы реальную картину видеть?

пробел перед запросом

Не работает

S.Chushkin

17.12.2015 - 19:06

Цитата (Serg86 @ 17.12.2015 - 17:51)

S.Chushkin Сможете в реальной базе глянуть? мож я че не так делаю, у меня ваших цифр и близко нет

1)
Настройки движка плохие для Ваших объёмов.
У Вас БД больше гига, а некоторые настройки рассчитаны на 100М.
например:
innodb_log_buffer_size 268435456
оптимально - объём буфера должен быть >= объёму БД.

и остальные настройки посмотрите - я не стал вникать в подробности.

2) Отображение строк 0 - 29 (30 всего, Запрос занял 0.0133 сек.)
Всё нормально, индекс используется.

3)

Цитата

Не прокатило
explain говорит key_len 5, rows 85700
Я так понял что только статус задействован

Как я уже говорил, основные тормоза у Вас были на "filesort". При использовании IDX вся выборка происходит по индексу. Т.е. сначала выборка по `status`(индекс), затем выборка 30 строк в порядке `raised`,`date_add`(индекс) с фильтрацией по cat`,`region`, значения которых берутся из индекса.
Принципиально быстрее вряд ли получится, - к сожалению mySQL не настолько умный. Думаю, если повозиться хорошенько, то можно ещё ускорить раза в два. Скорее всего это будет максимум возможного при такой структуре БД для такого запроса. Повторюсь - запрос не простой для движка.

_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru

Быстрый ответ:

Здесь расположена полная версия этой страницы.