Вопрос по оптимизации пагинации

[Василий М.]

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

Сейчас у меня в проекте есть каталог с вложенными друг в друга категориями.
Каждая строка в таблице каталога содержит кол-во записей, которые есть в категории. Количество записей, естественно, включая кол-во записей всех подчиненных категорий.
Это количество обновляется раз в 10 минут.

Пагинация работает с помощью SQL_CALC_FOUND_ROWS.

Вопрос - целесообразно ли избавляться от SQL_CALC_FOUND_ROWS и при построении пагинации использовать значение хранимое в СУБД?
Т.е. всегда и везде хранить кол-во записей в СУБД, что бы не делать SQL_CALC_FOUND_ROWS или count(*)?

 

[С.]

Естественно! Если уж денормализация произведена (да еще и синхронизируется каждые 10 минут, что по-моему избыточно), то просто грех этим не пользоваться.

 

[Василий М.]

Почему избыточно? Всегда актуальные данные.

 

[Василий М.]

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

А если у нас есть поиск по каталогу? Все равно считать придется found rows? Как это обычно решается?

 

[MiksIr]

EXPLAIN-ом

 

[С.]

Почему избыточно? Всегда актуальные данные.

Зачем каждые 10 минут, а не когда произошло удаление или добавление?