Индексы есть — указаны в первом посте. Сервер нормальный. Не по последнему слову техники, но вполне приличный. Там стоит Intel с двойным ядром (Core Duo). Покупался год назад — тогда это был хороший проц. И 4 Gb оперативки.
Сейчас зашел в БД форума (на том же сервере). В таблице постов ~400 тыс записей, также есть столбец с timestamp. Сделал аналогичную выборку (без GROUP) — быстрее работает. 0.04 секунды. У меня же это 0.7.
Вопрос «как такое может быть» плавно перетекает в «какие для этого могут быть причины».
1. InnoDB использовать нерационально. Т.к. основное время идет именно выборка данных, а не вставка/обновление/удаление.
2. Какая разница какой тип поля используется для временной метки? А с timestamp работать проще (лично мне).
3. Кэш последних Х записей не поможет. Запросы идут не только к первым записям. А и к более ранним тоже. Если поисковый робот решит пройтись по страничкам — это будет все равно очень затратно по времени.
4. Думаю над тем как оптимально отмечать дубликаты при добавлении…
На сервере. Удаленном. Выделенном. Там несколько мелких сайтов (до 10).
Посещаемость очень низкая. сегодня на сайте было 39 человек. В данный момент там я и еще один человек (судя по статистике)
Хотя признаю, что в плане LIMIT-а Вы правы. Если убрать группировку, скорость запроса снижается пропорционально количеству пропускаемых строк. Это логично и это понятно.
Думаю, что в итоге откажусь от него. Однако сначала нужно решить проблему с дубликатами.
Они и так кэшируются. Если такой запрос был сделан ранее, то он отрабатывает за 0.0002 секунды.
Проблема в том, что если добавится хотя бы одна новость в базу, то кэш уже не поможет — опять будет задержка у первого, кто запросит новости.
Лично я бы сам ушел с сайта, страницы которого грузятся 5 секунд!
Попробовал без всякой группировки. Из условий осталось только ORDER BY timestamp DESC. Запрос обрабатывается 0.2 секунды. Это вообще нормально для 70 тыс записей?
Я тоже думаю, что это немного. Работал и с большим объемом. Было быстрее, чем сейчас.
Если добавить MD5, то запрос отрабатывает примерно за 3 секунды. Это долго.
Пропуски есть. Я читал про то, что можно обойтись без LIMIT-а и как это сделать. Просто в данный момент проблема не в сдвиге, а именно в группировке, т.к. после обновления базы (когда кэш сбросился) получение первых 10 элементов также занимает 4-5 секунд.
Я думал над этим. Оказалось довольно сложно.
В таблице большой объем данных. Добавляются новые записи каждые 20 минут. Получается, что каждые 20 минут нам нужно для каждой новой записи пробежать по всему массиву данных и понять — была уже такая новость или нет. Если была — берем ее ID и записываем «для этой новости есть еще и другой раздел».
Я правильно понял идею? Хранить только уникальные новости, а дублирование выносим в промежуточную таблицу. Проблема в ресурсоемком вычислении «дубликатов». Сравнение-то по url (строка переменной длины).
Сейчас зашел в БД форума (на том же сервере). В таблице постов ~400 тыс записей, также есть столбец с timestamp. Сделал аналогичную выборку (без GROUP) — быстрее работает. 0.04 секунды. У меня же это 0.7.
Вопрос «как такое может быть» плавно перетекает в «какие для этого могут быть причины».