Форум пользователей MySQL

Попробуйте FORCE INDEX. Оптимизатор считает, что один раз пройти всю таблицу проще, чем 500 раз пройти по индексу, и, возможно, это правда.

Proger написал:

но все равно using_filesort

Потому что сортируете по полю `TIME`, которое не входит в левый префикс ни одного из ключей.

Отредактированно coin (14.02.2009 23:37:53)

Индексы сортируются примерно так:

`uid`   `TIME`
0    2009-02-14 23:59:47
0    2009-02-14 23:59:47
0    2009-02-15 00:06:47
1    2009-02-14 23:58:47
1    2009-02-15 00:01:47
1    2009-02-15 00:07:47
2    2009-02-15 00:07:47
3    2009-02-15 00:08:47
4    2009-02-15 00:05:47
4    2009-02-15 00:07:47
5    2009-02-15 00:06:47
6    2009-02-15 00:00:47
6    2009-02-15 00:01:47
6    2009-02-15 00:05:47
7    2009-02-15 00:01:47

Т.е. происходит общая сортировка по первому полю и у групп с равными `uid` записи отсортированы по второму полю `TIME`. А вы хотите от такого индекса общую сортировку по второму полю.
С этим индексом можно работать только по левому префиксу полей:
1) либо `uid`
2) либо `uid`,`TIME`

Насчёт правильного индекса врятли помогу..

Я бы создал индекс `TIME`,`uid` и использовал бы запросы вроде:

SELECT *
FROM `infosystem` USE INDEX (`имя индекса`)
WHERE
`TIME` BETWEEN CURRENT_DATE-INTERVAL 5 DAY AND CURRENT_DATE-INTERVAL 4 DAY
AND
`uid` IN ( 2, 4, 5, 6, 7, 16, 18, 20, 24, 26, 32, 33, 34, 37, 38, 39, 42, 44, 45, 66, 67, 68, 71, 73, 1001, 1002, 1005 )
ORDER BY `TIME`

Т.е. что то вроде постраничной навигации по суткам.

coin, сделал так (индекс не подрубился). Навигация по дням мне тут не пригодится. Но в другом месте уже пригодилась - спасибо.
Вот только не понимаю чего делать ибо индексы не работаюсь, а какой тогда алгоритм выбирать фигзнает ((

Пользователь делает что-то, например пишет другому комментарий на запись в блоге и это добавляется в таблицу infosystem и как бы тут же любой друг этого пользователя может это увидеть (на странице "новости друзей") и пройти почитать его комментарий и ту запись в блоге которую он комментировал. Как тут иначе то сделать? Создавать по записи на каждого друга? А если друзей 1000 ? ммм... я погряз в глубоких раздумьях...

Отредактированно Proger (15.02.2009 00:58:29)

КСТАТИ! Я тут подумал. А если сортировать на стороне php? То есть только выборку по UID IN() сделать, а отсортировать уже в php?

Ну да... наверное это самый оптимальный вариант. Только не FORCE INDEX, а USE чтобы оптимизатор сам там подумал что быстрее. Использовать кучу проходов по индексу или по таблице.

Отредактированно Proger (15.02.2009 01:21:10)

дык данные об активности людей автоматом чистятся. И выводится за последние несколько дней примерно.
Притом данные ещё проходят парсер. Который например группирует одинаковые события. Например человек загрузил 100 фотографий мне что о каждой фотке отдельный раз информацию вывести? Нет я просто беру и пишу юзер "загрузили фото (N штук)".

Тут вопрос даже не в скорости, а в том чтобы запрос не падал в slow-query-log ибо мешает следить за другими неполадками.

Также подумываю сделать кеширование материала, чтобы генерировать всю информацию и парсить её в том числе один раз, а не при каждом просмотре.

Вообще, операция IN сама по себе долгая. Как я понимаю, набор значений, которые подставляются в IN получаются на основе каких-то запросов? Не получится ли сделать примерно так:

SELECT field
FROM (SELECT значения_которые_в_IN FROM tables WHERE условия_использующие_индексы) t1
JOIN infosystem ON infosystem.uid = t1.данные

ИМХО, в этом случае индексы должны будут использоваться гораздо эффективнее. По крайней мере, у меня скорость подобного запроса на 2 000 000 строчках выросла с 4-5 минут до 5-7 секунд. Правда, это было на оракле, но не думаю, что в данном случае будет разница.

Ну в slow log он падает потому что у Вас или очень-очень медленный сервер, или таки включена запись
запросов без индексов. Для маленьких табличек - это нормально.

Magz написал:

Вообще, операция IN сама по себе долгая.

Операция IN нормальная, быстрая.
Прекрасно понимает индексы.

Проблемы возникают если источник IN не константа - подзапрос.
Оптимизатор MySQL криво их отрабатывает, может выполнить его далеко не один раз.
http://sqlinfo.ru/forum/viewtopic.php?id=559

Я эту проблему для себя решил
Подобные конструкции заворачиваю в ХП.
Разбиваю на два запроса.

Сначала выполняю подзапрос, результат загоняю в строку через GROUP_CONCAT.
SELECT GROUP_CONCAT(bla) FROM blabla WHERE id = 1 INTO blablabla;

Затем собираю строку основного запроса
@qry = CONCAT("SELECT id FROM test WHERE test.bla IN (" , blablabla, ")";

Дальше через PREPARE его выполняю
http://sqlinfo.ru/forum/viewtopic.php?id=363

В результате жестко выполняю подзапрос ОДИН раз и не имею проблем с оптимизатором.

В приведенном примере второй запрос будет работать дольше, т.к. будет
использоваться временная таблица.

Magz написал:

EugeneTM написал:

Magz написал:

Вообще, операция IN сама по себе долгая.

Операция IN нормальная, быстрая.
Прекрасно понимает индексы.

Я имел ввиду, что поиск каждого значения из IN происходит по полной таблице. Да, индекс, конечно, используется, но запорс, где в IN стоит два значения практически равен двум отдельным запросом. Вернее, сопоставим с выполнением двух отдельных запросов с равенством. И чем больше значений в IN, тем тяжелее получается запрос. Естественно, это заметно на больших объемах данных.

Код:

SELECT * FROM Table WHERE f IN (1,2)
// Сопоставим с 
SELECT * FROM Table WHERE f =1 UNION SELECT * FROM Table WHERE f =2

Возможно, я не прав, к этому выводу я пришел самостоятельно после большого числа экспериментов.

Не прав
Explain посмотри, по сути то же самое что и WHERE id = const

PS.
В него вообще почаще заглядывать нужно, он может фингню делать, но как правило не врет.
В смысле что пишет, то и делает