Комментарии 79
Прошу прощения за «чайницкий» вопрос, но зачем в «двух классически используемых запросах» первый запрос? Разве второй не возвращает искомое количество строк, удовлетворяющих условию?
Он нужен для «пагинатора». COUNT(*) вычисляет общее количество строк удовлетворяющих условию (всего страниц, например), а первый достает некоторый кусочек этих данных (выбранная страница, в данном случае 2-я).
картинок не видно у меня
Она всего одна. На гугловском Picasa Web Albums. Должно работать хорошо.
аналогично картинку не вижу
странно, если открыть картинку в отдельном окне, то она показывается
может так кто увидит yfrog.com/7ddiagrammag
может так кто увидит yfrog.com/7ddiagrammag
>>Mysql> SELECT SQL_CALC_FOUND_ROWS * FROM table WHERE column > 1 LIMIT 50, 50;
>>Mysql> SELECT FOUND_ROWS();
>>Несмотря на то, что первый запрос вернёт 50 строк, результатом будет «100», т.к. mySQL пришлось просмотреть именно 100 строк.
Если я не ошибаюсь в этом примере SQL_CALC_FOUND_ROWS лишний, так как с ним FOUND_ROWS вернёт всё-таки число строк в таблице удовлетворяющих условию, а не количество просмотренных строк.
>>Mysql> SELECT FOUND_ROWS();
>>Несмотря на то, что первый запрос вернёт 50 строк, результатом будет «100», т.к. mySQL пришлось просмотреть именно 100 строк.
Если я не ошибаюсь в этом примере SQL_CALC_FOUND_ROWS лишний, так как с ним FOUND_ROWS вернёт всё-таки число строк в таблице удовлетворяющих условию, а не количество просмотренных строк.
статья интересная, однако большой минус автору использующему даже в примерах select count(*) — помните — использовать в запросах * это как минимум медленно, как максимум плохой тон.
всегда пишите поля которые вам нужно выбрать.
всегда пишите поля которые вам нужно выбрать.
я читал обратное.
не подкрепите свои слова ссылкой?
не подкрепите свои слова ссылкой?
и правда странное утверждение.
как сказано в мане: для таблиц HEAP и MyISAM функция COUNT(*), которая вызывается для одной таблицы и не содержит предложения WHERE, берется непосредственно из табличной информации.
как сказано в мане: для таблиц HEAP и MyISAM функция COUNT(*), которая вызывается для одной таблицы и не содержит предложения WHERE, берется непосредственно из табличной информации.
maisonbisson.com/blog/post/11796/easy-mysql-performance-tips/
вот почитайте и сходите в гугл по запросу mysql count(*) perfomance
вот почитайте и сходите в гугл по запросу mysql count(*) perfomance
для COUNT это не имеет значения, хотя я, обычно пишу COUNT(id), где id — PK
count(*) работает гораздо быстрее, чем count(field)
Где про это почитать?
phpclub.ru/detail/article/mysql_optimize тут рассказано, еще где-то в мануале было, там, где про оптимизацию.
А чего минусовать-то? Проверяйте не на бестолковом запросе, типа «select count(*) from table» а на реальном с WHERE — разница в разы.
все верно.
в pgsql тоже так.
если указывать (*) то база сама найдет поле с лучшим для нее индексом для подсчета.
если указывать конкретно поле, то это может стать не лучшим выбором для скорости.
все можно проверить тестами.
в pgsql тоже так.
если указывать (*) то база сама найдет поле с лучшим для нее индексом для подсчета.
если указывать конкретно поле, то это может стать не лучшим выбором для скорости.
все можно проверить тестами.
Читаем внимательно мануал по COUNT.
Звездочка в COUNT и звездочка в списке полей для выборки ничего общего не имеют.
Звездочка в COUNT и звездочка в списке полей для выборки ничего общего не имеют.
ага, только это относится к майисам, даю 100 в гору что привычка превыше всего и автор пишет и в иннодб так что замедлит запрос. так что мыслить шире надо, а не только применять все к myisam
это относится только к 1 типу запросов — запросы без WHERE.
да что за чушь.
count(*) всегда быстрее чем count(expr). Ибо count(expr) должен применить expr на каждый ряд и вывести то, где не получилось в итоге null. А count(*) возвращает явно число вернувшихся рядов и все. Другими словами:
select count(*) from table where mycol is not null
select count(my_col) from table
абсолютно одинаковые. А значит делать count(id) это равнозначно дописыванию ненужного where id is not NULL в запрос. Оптимизатор это схавает, но не всегда.
в MyISAM у метаифы в таблице вообще явно записано число рядов. Следовательно, простой запрос select count(*) from table можно вообще не исполнять — а просто выплюнуть это число. В innodb не прокатит, т.к. в 1 момнет времени кол-во рядов в таблице может быть разным в разных транзакциях.
— а вы, фантазёры, блин.
count(*) всегда быстрее чем count(expr). Ибо count(expr) должен применить expr на каждый ряд и вывести то, где не получилось в итоге null. А count(*) возвращает явно число вернувшихся рядов и все. Другими словами:
select count(*) from table where mycol is not null
select count(my_col) from table
абсолютно одинаковые. А значит делать count(id) это равнозначно дописыванию ненужного where id is not NULL в запрос. Оптимизатор это схавает, но не всегда.
в MyISAM у метаифы в таблице вообще явно записано число рядов. Следовательно, простой запрос select count(*) from table можно вообще не исполнять — а просто выплюнуть это число. В innodb не прокатит, т.к. в 1 момнет времени кол-во рядов в таблице может быть разным в разных транзакциях.
— а вы, фантазёры, блин.
перечитай, пожалуйста, комментарий, на который я отвечал. я даже выделю тебе важную часть:
>> ага, только это относится к майисам, даю 100 в гору что привычка превыше всего и автор пишет и в иннодб так что замедлит запрос.
мой ответ:
>> это относится только к 1 типу запросов — запросы без WHERE.
я говорил только о SELECT COUNT(*) FROM `table` применительно к озвученным storage. ты понимаешь, что я ответил то же самое, что и ты?
habrahabr.ru/blogs/mysql/64655/#comment_1802657
теперь можешь выдыхать.
>> ага, только это относится к майисам, даю 100 в гору что привычка превыше всего и автор пишет и в иннодб так что замедлит запрос.
мой ответ:
>> это относится только к 1 типу запросов — запросы без WHERE.
я говорил только о SELECT COUNT(*) FROM `table` применительно к озвученным storage. ты понимаешь, что я ответил то же самое, что и ты?
habrahabr.ru/blogs/mysql/64655/#comment_1802657
теперь можешь выдыхать.
select * from и select count(*) from — это две большие разницы.
Более того, select count(*) from и select count(field) from вернут разные результаты, если в поле field есть стоки с NULL.
Более того, select count(*) from и select count(field) from вернут разные результаты, если в поле field есть стоки с NULL.
count(*) выберет количество найденных записей, не выбирая конкретные значения.
count(id) не только выберет записи, но и будет анализировать id, что дольше.
count(id) не только выберет записи, но и будет анализировать id, что дольше.
Таблица INNODB, тест на рабочем сервере
SELECT SQL_NO_CACHE count( * )
FROM song
(~3,329,071 всего, запрос занял 0.4882 сек.)
SELECT SQL_NO_CACHE count( song_id )
FROM song
(~3,329,071 всего, запрос занял 0.4811 сек.)
разница минимальна, Explain показвает практически одно и то-же.
SELECT SQL_NO_CACHE count( * )
FROM song
(~3,329,071 всего, запрос занял 0.4882 сек.)
SELECT SQL_NO_CACHE count( song_id )
FROM song
(~3,329,071 всего, запрос занял 0.4811 сек.)
разница минимальна, Explain показвает практически одно и то-же.
искренне рад, только вы нагрузите базу эдак на 1.5к запросов в секунду разнообразных и потом выполняйте вот такие подсчеты, вам эти микросекунды в сумму покажутся вечностью
Повторите тоже самое с уловием в WHERE типа «song_lenght > бла-бла-бла» или что-то типа того.
SELECT SQL_NO_CACHE count( song_id )
FROM song WHERE song_added = '2009-07-09'
запрос занял 0.0539 сек
результат 100714
SELECT SQL_NO_CACHE count( * )
FROM song WHERE song_added = '2009-07-09'
запрос занял 0.0512 сек.)
результат 100714
song_added естественно index
Explain одинаков
Думаю разница в пределах погрешности, ибо время выполнения запроса каждый раз прыгало на +-40мс
FROM song WHERE song_added = '2009-07-09'
запрос занял 0.0539 сек
результат 100714
SELECT SQL_NO_CACHE count( * )
FROM song WHERE song_added = '2009-07-09'
запрос занял 0.0512 сек.)
результат 100714
song_added естественно index
Explain одинаков
Думаю разница в пределах погрешности, ибо время выполнения запроса каждый раз прыгало на +-40мс
А вы RANGE запросы попробуйте, BETWEEN воткните по song_added ;-)
В исполком пришла жалоба:
«Напротив моего окна женская баня. Мне все видно и это отвлекает меня и вообще действует на мой моральный облик. Прошу предоставить мне новую квартиру».
Приехала комиссия, смотрят в окно.
— Ну и что? Ничего не видно!
— А вы на шкаф залезьте!
— Ну, залез, — говорит представитель, — все равно не видно!
— Двигайтесь левее…
— Все равно не видно!
— Еще левее!
Тут представитель двигается и падает с края шкафа.
— Вот видите! А я так целый день!
«Напротив моего окна женская баня. Мне все видно и это отвлекает меня и вообще действует на мой моральный облик. Прошу предоставить мне новую квартиру».
Приехала комиссия, смотрят в окно.
— Ну и что? Ничего не видно!
— А вы на шкаф залезьте!
— Ну, залез, — говорит представитель, — все равно не видно!
— Двигайтесь левее…
— Все равно не видно!
— Еще левее!
Тут представитель двигается и падает с края шкафа.
— Вот видите! А я так целый день!
а теперь давайте наконец включим голову и подумаем как сделать базе то, что вы от неё хотите.
1) count(*) (если без where и мы юзаем innodb) — то это просто вытащить длину любого ключа. Как правило — primary key. В queryplan будет type=index
2) count(col) заставит смотреть col is not null на каждом ряде. Если col проиндексирована, то результат будет почти такой же как и в 1 пункте, с той лишь разницей что тут тока btree индекс прокатит. Если же индекса нету — то будет *опа.
И ещё очень умно писать SQL_NO_CACHE там где кеша в принципе быть не может =).
1) count(*) (если без where и мы юзаем innodb) — то это просто вытащить длину любого ключа. Как правило — primary key. В queryplan будет type=index
2) count(col) заставит смотреть col is not null на каждом ряде. Если col проиндексирована, то результат будет почти такой же как и в 1 пункте, с той лишь разницей что тут тока btree индекс прокатит. Если же индекса нету — то будет *опа.
И ещё очень умно писать SQL_NO_CACHE там где кеша в принципе быть не может =).
Ну вот здесь www.mysqlperformanceblog.com/2007/04/10/count-vs-countcol/ пишут что для myisam count(*) всё же предпочтительней, и, чего я раньше не знал, COUNT(*) при возможности будет использовать подходящий индекс.
Для count(*) полностью наоборот.
субъективность данного теста по вопросом, так как не была использована деректива SQL_NO_CACHE
Когда производительность не имеет особого значения и важны удобство и скорость написания кода, то вполне можно использовать FOUND_ROWS() + SQL_CALC_FOUND_ROWS
Я что-то не понял, FOUND_ROWS() и SQL_CALC_FOUND_ROWS удобнее и быстрее чем COUNT() пишутся? Ну допустим. Поднимите, пожалуйста, руки, кто после этого поста сразу станет использовать FOUND_ROWS() + SQL_CALC_FOUND_ROWS.
у меня дежавю, но где-то недавно я уже про это читал, правда, на английском.
Думаю, в самом авторитетном источнике.
Для замеров времени выполнения запросов я бы прекомендовал использовать встроенное профилирование запросов в mySQL + можно получить дополнительную информацию о количестве оперативной памяти, проца и тд
dev.mysql.com/doc/refman/5.1/en/show-profiles.html
dev.mysql.com/doc/refman/5.1/en/show-profiles.html
Вообще, я категорически не советую на таблицах с тысячами строк использовать пагинатор на основе LIMIT, он ж будет тупо перебирать все записи.
Ради интереса, в постгресе:
1. Со астериском
EXPLAIN ANALYZE SELECT COUNT(*) FROM test;
Aggregate (cost=173166.50..173166.51 rows=1 width=0) (actual time=22994.037..22994.038 rows=1 loops=1)
-> Seq Scan on log (cost=0.00..164354.60 rows=3524760 width=0) (actual time=9361.992..21308.870 rows=3568867 loops=1)
Total runtime: 23017.941 ms
2. По primary key
EXPLAIN ANALYZE SELECT COUNT(test_id) FROM test;
Aggregate (cost=173166.50..173166.51 rows=1 width=8) (actual time=23320.353..23320.354 rows=1 loops=1)
-> Seq Scan on log (cost=0.00..164354.60 rows=3524760 width=8) (actual time=9604.659..20754.970 rows=3568867 loops=1)
Total runtime: 23320.404 ms
3. По индексу
EXPLAIN ANALYZE SELECT COUNT(test_time) FROM test;
Aggregate (cost=173166.50..173166.51 rows=1 width=4) (actual time=22335.123..22335.124 rows=1 loops=1)
-> Seq Scan on log (cost=0.00..164354.60 rows=3524760 width=4) (actual time=9584.735..20364.312 rows=3568867 loops=1)
Total runtime: 22335.177 ms
никакой разницы :)
1. Со астериском
EXPLAIN ANALYZE SELECT COUNT(*) FROM test;
Aggregate (cost=173166.50..173166.51 rows=1 width=0) (actual time=22994.037..22994.038 rows=1 loops=1)
-> Seq Scan on log (cost=0.00..164354.60 rows=3524760 width=0) (actual time=9361.992..21308.870 rows=3568867 loops=1)
Total runtime: 23017.941 ms
2. По primary key
EXPLAIN ANALYZE SELECT COUNT(test_id) FROM test;
Aggregate (cost=173166.50..173166.51 rows=1 width=8) (actual time=23320.353..23320.354 rows=1 loops=1)
-> Seq Scan on log (cost=0.00..164354.60 rows=3524760 width=8) (actual time=9604.659..20754.970 rows=3568867 loops=1)
Total runtime: 23320.404 ms
3. По индексу
EXPLAIN ANALYZE SELECT COUNT(test_time) FROM test;
Aggregate (cost=173166.50..173166.51 rows=1 width=4) (actual time=22335.123..22335.124 rows=1 loops=1)
-> Seq Scan on log (cost=0.00..164354.60 rows=3524760 width=4) (actual time=9584.735..20364.312 rows=3568867 loops=1)
Total runtime: 22335.177 ms
никакой разницы :)
а помойму почти 0.5% =) Тем не менее, count(*) даже писать проще. А count(col) надо использовать только когда действительно нужно не просто кол-во рядов.
Ну так в постгресе для вычисления count нужно все записи просканировать, т.к. там агрегатные ф-ии по-другому реализованы. Как ни пиши, все равно будет seq scan (если без WHERE).
а что с автором статьи? инвайт нужен?
Это MyISAM, какова ситуация с InnoDB — COUNT там весьма ресурсоёмкий
Надо было InnoDB добавить в тест, а также count(1) и count(field) и всё это в одну таблицу, а то споры в этой области будут ещё долго.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Подсчёт общего количества строк выборке в mySQL при использовании LIMIT