Медленное условие в запросе sql?

Question

[Оптимус Пьян]

В таблице с 3 млн. записей. Первый запрос работает очень быстро:

SELECT SQL_NO_CACHE `id`,`users`
FROM `table` WHERE `users` > 3000 ORDER BY `users` DESC LIMIT 0,10

Но стоит добавить условие WHERE `date` IS NULL (по date есть индекс, но в нём половина повторов), как время выполнения падает до 8 секунд.

SELECT SQL_NO_CACHE `id`,`users`
FROM `table` WHERE `date` IS NULL AND `users` > 3000 ORDER BY `users` DESC LIMIT 0,10

explain второго запроса показывает возможные ключи users,date используется users. Тип range, а rows 259 тыс.
Как лучше поступить в этом случае?

Comments

[shagguboy]

explain extended покажи

[AlikDex]

порядок условий для индекса крайне важен. Поэтому следует проверить, чтоб соответствовало индексу.

[Оптимус Пьян]

shagguboy: Всё то же самое
select_type - SIMPLE
filtered - 100.00
остальное как писал выше

[Оптимус Пьян]

AlikDex: интересная мысль, спасибо, сейчас попробую

[Оптимус Пьян]

AlikDex: Порядок условий where поменял, поставил WHERE `users` > 3000 вперёд, но то же самое 8,7 секунд...

[AlikDex]

Дмитрий: а индекс какой? в вашем случае нужен индекс: date | users, если нуллевых дат мало (гуглить селективность).

[Оптимус Пьян]

AlikDex: индекс тот же users | date используется users да я знаю что нулевых дат много, но не знаю что с этим поделать

[AlikDex]

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

[Оптимус Пьян]

AlikDex: я хотел сделать подзапрос сначала с WHERE `users` > 3000 и сократить объём строк в 10 раз и уже в них искать нулевую дату, но что-то не вышло. Такой запрос так же показывает 8 секунд:

SELECT `id`,`users` FROM `table` WHERE `date` IS NULL AND `id` IN (SELECT `id` FROM `table` WHERE `users` > 3000) ORDER BY `users` DESC LIMIT 0,10

[AlikDex]

Дмитрий: оставьте этот запрос:

SELECT SQL_NO_CACHE `id`,`users`
FROM `table` WHERE `date` IS NULL AND `users` > 3000 ORDER BY `users` DESC LIMIT 0,10

Сделайте индекс date | users

[Оптимус Пьян]

AlikDex: Спасибо, сделал, помогло. Вы не в курсе на сколько хуже ищется только по users в этом случае если отдельного индекса по users нет, а есть только такой составной.

[AlikDex]

Дмитрий: этот составной не будет использоваться. Т.к. порядок в условиях и в индексе должен быть идентичен. Но, в вашем случае можно сделать два раздельных индекса(на этом сэкономить память и время на операциях вставки\апдейта\делета), это отдельный date и отдельный users, повлияет на работу не существенно, к тому же вероятнее всего мускул сам совместит эти два индекса (он такое умеет, но не стоит на это полагаться все время). Почему именно в вашем случае это будет уместно - потому что поле users так или иначе проходится полностью практически (3к несоизмеримо с 3кк), поэтому date | users можно разбить. Но если появятся дополнительные условия, например "date is null and users between 150000 and 300000" то составной индекс будет необходим.

[AlikDex]

забыл добавить:

составной индекс будет необходим в дополнение к индеску users

[Оптимус Пьян]

AlikDex: Использовал его принудительно вместо простого только по users скорость почти не упала