У меня в локальной копии БД 1`965`603 записей, такой запрос в среднем выполняется за 1 секунду. Рабочий комп - Pentium M 1.6, 1Gb.

Сервер конечно мощнее, но и данных там больше.

Это говорит об отсутствии индекса. Или об использовании неправильного индекса.
давай начнем с цитирования структуры таблицы, включая индексы, и explain-а вот этого распоследнего запроса.

возможно, может понадобиться составной индекс user_id, date_time

Если в консоли выполнить запрос EXPLAIN select * from _info where (user_id=2) order by date_time desc limit 1; - что выведет?

Akina, 



выдает:

попробуй сделать 
оно уберет filesort и должно стать быстрее.

Feldmarschall, и правда! Теперь время выполнения такой выборки = 0.00. И колонка Extra показывает, что используется только where.

Мне только не понятно, почему не был создан индекс при создании базы данных? Я же явно указал -  KEY (date_time). Или тут дело именно в составном индексе?


Feldmarschall,  +1

Это сообщение отредактировал(а) Coder - 3.6.2008, 02:37

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

Coder, насколько я себе это представляю.
индекс - это файл, который, грубо говоря, состоит из пар "значение поля - позиция в файле", отсортированный по значению поля. 
Поиск по отсортированному списку происходит на порядки быстрее.
В случае с одиночным индексом он используется, но помогает выбрать только строки одного юзера - а их 17 тысяч. А их уже приходится сортировать заново - ведь индекс по дате здесь не получится использовать - он тоже по всему файлу строится, и без информации о юзере.
А составной индекс отсортирован по двум полям, то есть, имеет вид
1, 2001
1, 2002
1, 2003
2, 2001
2, 2005
5, 2008

соответственно, поиск сводится нахождению сначала юзера, а потом - максимальной даты для него.

Feldmarschall, доходчиво.

Помечаю вопрос ка решенный.