Пара вопросов спецам по мускулу

Это количество просмотров? Если да, то значит оно будет разное, и как мне кажется установка тройного индекса типа CREATE INDEX tr_index ON f_table(ok, view, ero)

может ускорить выборку, устраняя скользское место - HAVING - неиспользование оптимизации.

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

Но опять же без EXPLAIN трудно что-то сказать :)

тройной индекс возможно решение, но этими параметрами мало чего отсеивается, поэтому думаю что особо этот индекс нам не поможет )

ok - проверенная фотка.. т.е. почти все 1

ero - +18 таких очень мало, т.е. почти все 0

view - способ отображения, там тоже почти везде одно значение 0

А чем черевато having? я так понимаю это повторная проверка всех выбранных данных? только в этом проблема?

а да я проглядел. кроме left join, когда вы задаете дополнительные условия - используется временная таблица с сортировкой и листание идет по ней. А когда условий нет, mysql "листает" сразу по индексу (n.id) и быстро.

order by n.id desc limit $start,$per - вот это постраничное листание в приложении можно переосмыслить? например, передавать в url последний n.id ?

netwind, не желательно, а какой бы был тогда вариант?

Максимальный объем ограничен винтами.

Увы, не бывает такого, но кластер вещь великая. Но есть и другой рецепт см. ниже.

Не думаю. Если софт написан грамотно, то все что необходимо это минимизировать работу мускуля, а именно:

• тяжелые запросы кидать в кеш, идеально memcached
• софтом дергать не mysql, а mem.

В результате кроме уменьшения дисковой нагрузки получите еще и огромный резерв в процессорном времени. Разумеется mem тоже скушает памяти, но при условии "идеальной железо" в первую очередь рассматривайте грамотно собранную бздю с десятком палок по 2 гига.

Dimanych, зато не самый плохой метод. попробуйте убрать в запросе "$start," и увидите как он превращается в обычное считывание по индексам без временной таблицы. ( я надеюсь поля проиндексированы? )

В url нужно будет передавать ИД последней фотки с прошлой страницы ($lastid) и выбирать потом дополнительным условием "where n.id > $lastid ... order by n.id desc limit $per"

можно еще попробовать sort_buffer в mysql подкрутить, но при объемных данных это все мертвому припарки.

Точно! Не подумал как то что ему будет достаточно смотреть только с того id с которого я укажу.

Но по сути дела, если для первой страницы, то старт равен 0, разве в этом случае не получатся тоже самое по эффективности что ваш метод? ) (хотябы даже для первой страницы, а их я не более 10 разрешаю просматривать) А вообще щас сам проверю )

Я подозреваю,что у вас все тормоза возникают на сортировке, которая выполняется во временных файлах. Возможно, если в explain пропадет "Using filesort" - будет эффект. Кстати, вас тут уже не просто так просили показать explain запроса.

А потом, если результат неудовлетворительный, можно попробовать индекс по трем полям. Увлечение индексами не должно быть чрезмерным - их же нужно при изменениях в таблицах обновлять тоже.

Всё перепробовал и по id вместо лимита.. единственное что улучшает это having, почти в 10 раз быстрее, впринцепи устраивает, не знаю как будет при увеличении базы.

Explain этого запроса

это сейчас или раньше?

приведите полные тексты запросов и explain к каждому. и лучше без этой гадости phpшной - глаза сломать можно.