Форум MySQL

Доброго времени суток! По этому вопросу конечно много информации в интернете, но хотелось бы услышать мнение профессионалов.

Итак.... постраничная навигация......

До недавнего времени я думал, что SQL_CALC_FOUND_ROWS - единственное верное решение... Всегда стараюсь пользоваться штатными функциями, посему считал эту штуковину - дичайше полезным изобретением))....... Но недавно в интеренте прочитал очень ругательные отзывы... люди говорят, что эта штуковина дико тормозит и не использует индексы........ Лично проверил - реально очень сильно замедляет, хотя ИМХО индексы тут не причем, т.к. при индексировании скорость все равно увеличивается (значит индексы работают), но все равно работает в 5-10 раз медленнее, чем без применения Calc_rows.....

Получается, что единственным вариантом остается - делать 2 запроса..... 1 - count, 2- сам селект с LIMIT
Просто немного не нравится, что тяжелый запрос будет выполняться 2 раза.......
Собственно вопрос вот в чем...Есть ли какой-либо еще способ узнать сколько всего записей попадает под условие, без учета LIMIT?

Да, эти обвинения в сторону SQL_CALC_FOUND_ROWS не безпочвенные, запрос вынужден выполняться полностью. И если в случае COUNT(*) его можно оптимизировать, то в случае SQL_CALC_FOUND_ROWS избежать полного скана практически невозможно. Несколько запросов - это не страшно, главное, чтобы они быстро отрабатывали, страшно, когда выполняется большой медленый запрос, да к тому же блокирующий таблицу для остальных запросов.

Вообще в MySQL LIMIT и его обслуживание реализованы не самым блестящим образом, например при LIMIT 10000, 10 у вас будут выбраны все 10010 записей, благо что у пользователей терпения обычно хватает только на первые несколько страниц.

Спасибо большое за грамотный ответ! Теперь просто закрою эту тему и всегда буду использовать COUNT(*).... И главное, это меня научило - обязательно проверять такие штуки, которые, на первый взгляд, кажутся простыми и правильными, а на деле выходит все наоборот.........

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

Тут одной книгой обойтись не получится. Архитектура она обычно такие штуки как оптимизация игнорирует, более того, жертвует оптимизацией во имя стройности архитектуры и кода менее подверженного ошибкам. Когда же речь заходит об оптимизации, то, как правило, это всегда рефакторинг - т.е. оптимизация уже готового кода, так как со времен Дональда Кнута преждевременная оптимизация признана злом (не будем сейчас вдаваться в объяснения почему и как). Т.е. фактически нужно писать две книги - одна об архитектуре, другая об рефакторинге. Таких книг уже существует не мало, пусть не по PHP и Web. Да и сложно писать такие книги в условиях Web - слишком он разнокалиберный (то 1000 сайтов на одном сервере, то 1 сайт на 1000 серверах) и все постоянно меняется: мощность, мода, приоритеты, инструменты. Пишешь книгу - срок жизни ей 3 года, потом с 0 нужно переписывать.