|
Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1 2
paulus написал:
Вариант по умолчанию должен, разумеется, не считать count вообще.
Так и есть.
paulus написал:
Сигнализировать о том, как считать количество, можно в том же параметре, который передает количество
строк, которое нужно передать.
Это не совсем удобно. Почему - расскажу как-нибудь потом.
paulus написал:
Ну то есть я, если честно, не понимаю, почему мы это
обсуждаем на форуме о MySQL
Ну, Вася спросил, зачем мне это нужно, я и рассказал 
paulus написал:
Миш, ты пишешь ORM, возьми готовый какой-то.
Я пытался, но понял, что не написать свой я не могу
Да и вообще-то поздно отговаривать, т.к. я его уже написал, он работает . Осталось подготовить к нему пояснительную статью, чем сейчас и занимаюсь.
Неактивен
Я бы не использовал SQL_CALC_FOUND_ROWS вообще никогда. Дело в том, ситуации, когда с ним нет проблем - это ситуации, когда не нужна оптимизация, то есть запрос быстрый изначально. Если запрос тяжелый, то как уже подробно объяснил paulus, запрос с SQL_СALC будет медленнее двух запросов (нужно помнить, что если есть ORDER BY, то SQL_CALC почти гарантирует неоптимизируемый filesort). Нагружать юзера выбором опции не стоит - пусть потратит свое внимание на другие важные детали - трудно представить себе ситуацию, когда он захочет установить SQL_CALC - это может быть только, если два запроса будут работать медленно, но тогда SQL_CALC не поможет.
Неактивен
Убедили
Делаем COUNT(*) по умолчанию.
Маленький вопросик: бывает ли смысл внутри COUNT что-то вместо звездочки писать в данном случае?
Неактивен
Нет.
count(что-то) - это подсчет сколько раз это что-то не является null.
count(*) - в этом случае сервер знает, что выражение внутри скобок не может быть null. Здесь * это не аналог полного списка столбцов, они вообще игнорируются, а считаются только сами строки.
Неактивен
paulus написал:
Миш, ты пишешь ORM, возьми готовый какой-то.
Я пытался, но понял, что не написать свой я не могу smile
Да и вообще-то поздно отговаривать, т.к. я его уже написал, он работает smile. Осталось подготовить к нему пояснительную статью, чем сейчас и занимаюсь.
Опубликовал статью: http://webew.ru/articles/5096.webew
Всех с наступающим!
Неактивен
Мой ответ хоть и на старый пост, но думаю поможет определиться и другим посетителям в будущем использовать "SQL_CALC_FOUND_ROWS" или "count(*)".
Вот ответ техподдержки одного из хостинг-провайдеров по поводу нагрузки на CPU процессом mysqld:
"Высокую нагрузку на сервер создавали запросы к базе данных вашего сайта:
SELECT SQL_CALC_FOUND_ROWS p.`virtuemart_product_id` FROM `#_virtuemart_products`
Для исправления этой проблемы следует оптимизировать запросы к базе в скриптах сайта и хранение данных в самой базе, а также проставить индексы на часто используемые поля. Для этого следует обратиться к разработчику вашего сайта, либо к сторонним веб-специалистам."
Подобные ответы получал неоднократно на разных сайтах и хостингах.
Таким образом, можно говорить о крайней нежелательности использования в запросах "SQL_CALC_FOUND_ROWS".
Неактивен
Все-таки есть случаи, когда SQL_CALC_FOUND_ROWS быстрее двух запросов.
Это сложные запросы с группировкой и сортировкой/HAVING по неиндексированным колонкам или вообще выражениям, вычисляемым на ходу. Например:
SELECT a.id FROM a JOIN b ON b.a_id = a.id GROUP BY a.id HAVING SUM(b.x * b.y) > 1000 ORDER BY SUM(b.x * b.y) DESC LIMIT 1
Чтобы отдать часть записей, серверу все равно нужно перелопатить весь запрос, поэтому SQL_CALC_FOUND_ROWS его не замедлит. А вот второй запрос с COUNT(*) будет выполняться столько же, сколько первый, что даст замедление в два раза.
Однако если все-таки ставить вопрос ребром: или COUNT(*), или SQL_CALC_FOUND_ROWS, не глядя на запрос, то выбор по-прежнему за COUNT(*). И вот почему.
Медленный запрос с COUNT(*) станет в два раза медленее. Но это не страшно. Потому что он итак медленный.
Быстрый же запрос с SQL_CALC_FOUND_ROWS может стать скачкообразно медленнее. Не в два раза, а в десятки раз. И вот это плохо. Потому что тогда вместо медленных запросов, которые стали в два раза медленнее, и запросов быстрых мы получим исходные медленные и еще одни медленные, в которые превратились быстрые.
В общем, я примерно повторил то, что ранее писал Гриша
rgbeast написал:
трудно представить себе ситуацию, когда он захочет установить SQL_CALC - это может быть только, если два запроса будут работать медленно, но тогда SQL_CALC не поможет
Неактивен
Страниц: 1 2
