Когда я должен рассмотреть сохранение общего количества в поле?

Question

Например, если мне нужно сосчитать комментарии, относящиеся к статье, очевидно, что мне не нужно кэшировать общее количество комментариев.

Но что, если я захочу разбить на галерею (статус WHERE = 1), содержащую 1 миллион фотографий. Должен ли я сохранить это в таблице с именем count или SELECT count (id) как итоговое значение каждый раз, когда все в порядке?

Есть ли другие решения?

Пожалуйста, сообщите. Спасибо.

Answer 1

Для MySQL вам не нужно хранить счетчики, вы можете использовать SQL_CALC_FOUND_ROWS, чтобы избежать двух запросов.

например.,

SELECT SQL_CALC_FOUND_ROWS * 
FROM Gallery
WHERE status = 1
LIMIT 10;
SELECT FOUND_ROWS();

Из руководства:

В некоторых случаях желательно знать, сколько строк в операторе вернулся бы без предела, но без запуска Снова Чтобы получить это количество строк, включите SQL_CALC_FOUND_ROWS параметр в инструкции SELECT, а затем вызвать FOUND_ROWS () после.

Пример использования здесь .

Answer 2

Это немного зависит от количества запросов, выполненных в этой таблице с 1 миллионом записей. Подумайте только о том, чтобы позаботиться о хороших индексах, особенно о многостолбцовых (потому что их легко забыть: здесь. Это будет много. И убедитесь, что запросы также хорошо кэшируются на вашем сервере.

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

Лучшая попытка: настройте некоторые тесты, чтобы выяснить, может ли запрос быть быстрым и производительность не падает, если вы выполняете его много раз подряд.

EXPLAIN [QUERY] 

Используйте эту команду (в MySQL), чтобы получить информацию о том, как выполняется запрос и можно ли его улучшить.

Answer 3

Делая счет каждый раз, все будет в порядке.

Во время подкачки вы можете использовать SQL_CALC_FOUND_ROWS в любом случае

Примечание:

1. AДенормалированный счет станет устаревшим
2. Никто не будет публиковать столько элементов