Форум пользователей MySQL

Порой отдельный запрос с count(*) может быть намного быстрее, если удастся использовать покрывающий индекс.

Порой отдельный запрос с count(*) может быть намного быстрее, если удастся использовать покрывающий индекс.

То есть? Ты хочешь сказать, что один запрос

будет работать медленнее, чем два отдельных

?
Как-то это странно. Я думал, что LIMIT с точки зрения индексов на скорость запроса не влияет, и один запрос, пусть с SQL_CALC_FOUND_ROWS - это в любом случае не хуже, чем один такой же, только без SQL_CALC_FOUND_ROWS и еще один с COUNT(*).

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

As soon as MySQL has sent the required number of rows to the client, it aborts the query unless you are using SQL_CALC_FOUND_ROWS.

Засчет того, что запрос от LIMIT и без SQL_CALC_FOUND_ROWS становится легче, а простой COUNT(*) хорошо ляжет на индексы, два запроса могут действительно оказаться быстрее одного. Пожалуй, ты прав.

А для каких целей ты его хочешь использовать?

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

Заковыка тут вот в чем.
Обычно удобно иметь некую функцию/метод, которая принимает какие-то параметры-ограничения будущего списка, а в ответ возвращает часть этого списка (обычно не больше какого-то фиксированного числа строк). Тут все просто. Вот только бывает нужно еще и узнать, а сколько строк всего, помимо этих выбранных. И вот тогда начинаются неудобства: где это число передать? Пихать в результат работы функции неудобно, потому что тогда надо возвращать не просто список строк, а массив, где в одном элементе - список, в другом - общее количество. В результате вместо простого и понятного выражения вида

получается

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

Тут, с одной стороны, сохранена лаконичность, с другой стороны, ясно, что откуда берется.

Исходный вопрос был навеян, прежде всего, необходимостью понять, важно ли с точки зрения производительности, что человек попросил посчитать общее количество строк, или же можно добавлять в запросы SQL_CALC_FOUND_ROWS в любом случае.
Хотя я и хочу отметить, что случай, когда SQL_CALC_FOUND_ROWS ощутимо повлияет на производительность, я считаю весьма редким, для порядка стоит все-таки это учитывать. Благо, это легко сделать, просто посмотрев с помощью  func_num_arg(), передал ли человек последний аргумент, предназначенный для записи в него  общего количества найденных строк.

Выбор же между SQL_CALC_FOUND_ROWS и дополнительным запросом с COUNT(*) - это вопрос, лежащий несколько в другой плоскости. Пока я придерживаюсь мнения, что следует пользоваться традиционным средством - SQL_CALC_FOUND_ROWS. Если выяснятся особо тяжелые случаи, когда нужно обязательно использовать COUNT(*), этого можно добиться, например, если в $count передавать не пустую переменную, а уже содержащую, например, единицу или что-то еще. Хотя она будет в итоге перезаписана, это позволит внутри функции разобраться, какой из вариантов использовать.
Впрочем, повторяю, я считаю этот случай довольно редким и, пока не назреет такая необходимость, вариант с COUNT(*) включать в функцию не буду.

Все вышесказанное реализовано в инструменте для построения выборок из БД (читай - ORM), который я разработал и сейчас пишу по нему статью, так что скоро будет на что посмотреть конкретно.

Имхо, SQL_CALC_FOUND_ROWS это зло и то, что люди считают это традиционным средством - опасное заблуждение.

Вот представь, что ты выводишь список статей с разбивкой на страницы. В случае SQL_CALC_FOUND_ROWS будет выбраны текстовые поля (анотация, название, автор) для всей сотни страниц.

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

Что же касается конкретно разбивки на страницы, то можно делать выборку limit N+1 и две ссылки (следующая и последняя). При этом не обязательно знать сколько всего записей.

Вот представь, что ты выводишь список статей с разбивкой на страницы. В случае SQL_CALC_FOUND_ROWS будет выбраны текстовые поля (анотация, название, автор) для всей сотни страниц.

Нет, потому что я предписываю сначала выбирать нужные id, а потом для них данные.

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

Это если, убрав SQL_CALC_FOUND_ROWS, ты получишь хороший запрос по ключу. В противном же случае последующий COUNT(*) будет не лучше, чем SQL_CALC_FOUND_ROWS.

Все же я считаю это редким случаем (см. мой ответ выше на сообщение rgbeast).

Что же касается конкретно разбивки на страницы, то можно делать выборку limit N+1 и две ссылки (следующая и последняя). При этом не обязательно знать сколько всего записей.

Вот это вообще не понял.
Мне нужно разбить записи по 20 штук на страницу. Как я узнаю, сколько мне ссылок выводить на страницы, если не знаю, сколько у меня всего записей и, таким образом, не знаю, сколько они занимают страниц?

LazY написал:

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

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

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

rgbeast написал:

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

Добавление SQL_CALC_FOUND_ROWS делает невозможным оптимизацию этого запроса, если он станет медленным.

Если так случится - дополню функцию так, чтобы была вместо SQL_CALC_FOUND_ROWS использовать COUNT (о чем я писал выше), это несложно.

rgbeast написал:

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

Вот это я совсем не понял. Само использование SQL_CALC_FOUND_ROWS является преждевременной оптимизацией? Или отказ от SQL_CALC_FOUND_ROWS является преждевременной оптимизацией?

rgbeast написал:

Если речь о высоконагруженных системах, то технические требования накладывают очень серьезные требования на интерфейс.

Если уже после утверждения бюджета -то да

rgbeast написал:

Использование SQL_CALC_FOUND_ROWS - это замена двух запросов на один изощренный. Оправдание в том, что якобы иногда это экономит немного времени.

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

rgbeast написал:

Бывает, что ограничения не зависят от бюджета. Например, в онлайн-играх (MMORPG) есть интерфейсные вещи, которые вообще нельзя реализовать.

Ну, это конечно.
Я исключительно веб-приложения имел в виду.

rgbeast написал:

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

Тогда уж лучше наоборот сделать через SQL_CALC_FOUND_ROWS, а оптимизацию доверить серверу , как это и закладывалось разработчиками MySQL (иначе SQL_CALC_FOUND_ROWS не было бы как такового и не было бы практики его использования).
Так получается удобней с точки зрения клиентского приложения: у тебя один запрос, и WHERE и пр. локализованы в одном месте, отдельно остается только вызвать FOUND_ROWS(). В случае же с COUNT(*) запрос нужно очищать от ORDER BY и LIMIT и выполнять отдельно в другом месте в измененном виде. Такой код менее удобно поддерживать, чем написанный на основе SQL_CALC_FOUND_ROWS.

За пять лет мы набрались опыта и стали мудрее

rgbeast написал:

Становится понятно, что реализация от MySQL либо сделана настолько грубо, что рекомендовать эту фичу в продакшене нельзя.

Прямо уж так и нельзя? Я этим пользуюсь много лет и проблем не знаю (и не только я). Это факт.
Наверное, могут быть проблемы с производительностью в каких-то случаях, но в остальных случаях (которых больше) отказ от более удобного с точки зрения API метода в пользу теоретически более производительных, но громоздких вариантов выглядит как яркий пример преждевременной оптимизации.
Примечание: само наличие SQL_CALC_FOUND_ROWS не стоит рассматривать как преждевременную оптимизацию, потому что это, в первую очередь, интерфейсный инструмент, а не оптимизация как таковая. Да и, в любом случае, это часть MySQL. Разработчик клиентского приложения с точки зрения преждевременной оптимизации рассматривает свой код, а не механизм базы данных.

rgbeast написал:

люди не используют, а вендор не развивает

Ну как же не используют? Набери SQL_CALC_FOUND_ROWS в поисковике - увидишь, сколько упоминаний.
А вендор не развивает, возможно, потому, что не такая уж частая проблема (именно проблема, а не случай использования). Оптимизации подзапросов в SELECT вон сколько дожидались, а проблема была более очевидная.

Ох, какой вы флейм развели, давайте я в нем тоже поучаствую

1. Миш, ты гордишься тем, что ты программист. Посмотри на эту штуку не с точки зрения
«написали, давайте заюзаем», а с точки зрения здравого смысла. CALC_FOUND_ROWS
работает так: считает количество строк, которое выведет этот запрос без LIMIT. Т.е. берет
первую строку, считает, берет вторую строку, считает, берет третью строку, считает, и т.д.

2. SELECT COUNT(*) подвержен некоторым оптимизациям. Например, в случае с MyISAM,
он сразу знает ответ. В случае с InnoDB он вынужден бежать по PK, но он никогда не
заглядывает в листья за данными.

3. Наконец, в самом худшем случае, когда и тот, и другой алгоритмы вынуждены просма-
тривать и считать строки, случай с COUNT(*) не требует передачи самих данных в считалку
(а COUNT_FOUND_ROWS требует, т.к. иначе не умеет).

По сути, COUNT(*) отдельно работает всегда не медленнее, чем вариант «в лоб».

Вариант по умолчанию должен, разумеется, не считать count вообще. Сигнализировать
о том, как считать количество, можно в том же параметре, который передает количество
строк, которое нужно передать. Ну то есть я, если честно, не понимаю, почему мы это
обсуждаем на форуме о MySQL

getlist(array('user_id' => 17), array('limit' => 100, 'count' => 1))

Миш, ты пишешь ORM, возьми готовый какой-то.