Не работает count mysql

jumash:
Покажите — что выдаёт SELECT DISTINCT tovar_cat FROM lot;

Есть ли там вообще такая категория?

$q=»SELECT DISTINCT tovar_cat FROM lot»;

Там еще есть много других значений.

Вот мне надо чтоб посчитать не все

но 3500 это общее число всех значений . А мне надо только по конкретному условию

Допустим имеем nabor повторяется 10 раз.

значит надо чтоб where отдал 10

имеем musa 20 значит при запросе

получить число повторений тоесть значение 20.

А вот как сделать не пойму.

Eagle:

То что надо Спасибо Огромное.

Eagle:

Не очень хорошее решение — а если там очень много записей?

ТС — чтобы вывести — сколько всего и где —

$query = «SELECT COUNT(*), tovar_cat FROM lot GROUP BY tovar_cat»;

echo $row[0].» записей в категории «.$row[1].»
«;

Первый запрос у вас верен — проверьте — есть ли там такая категория в целом.

То есть безошибочно есть — SELECT COUNT(*) from lot WHERE tovar_cat=’nabor’;

Безошибочно, судя по всему, нет — platye

Хех, как Вы политкорректно заменили «глупости» 🙂

Возможно, я не достаточно хорошо разбираюсь в mysql, но чем плоха функция аффектед_роуз()?

jumash:
Не очень хорошее решение — а если там очень много записей?

ТС — чтобы вывести — сколько всего и где —

$query = «SELECT COUNT(*), tovar_cat FROM lot GROUP BY tovar_cat»;
$res = mysql_query($query);
while($row = mysql_fetch_row($res)) <
echo $row[0].» записей в категории «.$row[1].»
«;
>

Первый запрос у вас верен — проверьте — есть ли там такая категория в целом.

То есть безошибочно есть — SELECT COUNT(*) from lot WHERE tovar_cat=’nabor’;

Безошибочно, судя по всему, нет — platye

Ваш код выдает также что нужно

1 записей в категории nabor

2311 записей в категории platie

seosniks:
Ваш код выдает также что нужно

1 записей в категории nabor
2311 записей в категории platie

А вы сами и ответили на вопрос, судя по всему — у вас ошибка в первом топике — в запросе — platye != platie 🙂

jumash добавил 24.05.2009 в 13:14

Функция волшебна, несомненно

Но вот незадача

mysql_affected_rows() не работает с SELECT — только с запросами, модифицирующими таблицу. Чтобы получить количество рядов, возвращённых SELECT-запросом, используйте функцию mysql_num_rows().

Проверять лениво — допускается ли с SELECT — но я собственно не поэтому заменил «глупости» — у вас пример хороший, но недоточен. Например, если в таблице будет к примеру 1kk записей — скрипт рискует повесить сервер. Поэтому более красивое в этом случае решение — это использовать SQL_CALC_FOUND_ROWS.

То есть — SELECT SQL_CALC_FOUND_ROWS * FROM lot WHERE . LIMIT 1;

запрос который выведет количество выбранных рядов —

как-то так — путано, но понятно

Спасибо всем за Вашу помощь. Мн главное получить значения далее я думаю смогу разобраться..

И еще вопрос такой.

Есть у меня пагинатор. Вывводит все страницы на сайте.

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

В категории свои страницы?

Я сделал для категории свой пагинатор чтоб проще было. 😀

тоесть в категории например про вино есть 100 статей

на страницу вводиться 10 статей

в итоге пагинатор имеет значения 12345678910

Источник

Почему так по-разному работает COUNT(*) в MySQL?

Прекрасно знаю, что COUNT(*) в InnoDB не торт. Но не до такой же степени!

Есть две таблицы:

Вроде как никаких чудес, таблицы почти идентичны (не считая сложности второй), работа с ними идёт равно активно (они, вообще, для двух частей одних и тех же данных и 99% обращений идёт к обеим таблицам сразу).

Так вот, COUNT(*) во второй выполняется за ожидаемые 0.47 сек на холоде. Первая же таблица выполняет COUNT(*) за 7-10 минут!

Дело не в дисках, не в фрагментации — недавно вся БД переносилась на другой раздел, ничего не меняется.

Остальная работа (извлечение записей по индексам, JOIN, сортировки) работает отлично.

Есть мысли с чем такое поведение может быть связано?

Дело не в дисках, не в фрагментации — недавно вся БД переносилась на другой раздел, ничего не меняется.

дык. план что показывает? fullscan по единственному индексу?

Хм. Как-то не подумал я план для COUNT(*) посмотреть. Но в обоих случаях — Using index:

Вот что отличается — это длина ключа. 1 в «быстрой» таблице, 4 — в «медленной». Может, в этом дело? Типа, влезает/не влезает в какой-то из кешей… query_cache_limit у меня 4Мб… Но как-то не представляю, чтобы он был связан с запросом COUNT(*)…

Парсер на ЛОРе опять сломали? Код + — в code-блоке автозаменяется на ± 🙂

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

Переход на полное сканирование таблицы может быть как-то завязан на присутствие или даже возможность присутствия NULL значений в полях

Иногда, эту хрень (mysql/mariadb) надо просто перезапустить.

Но как? Вот, тупо в code-блоке:

Иногда, эту хрень (mysql/mariadb) надо просто перезапустить.

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

быстрым, он будет если только сразу возьмёт количество из какойнить внутренней табличной переменной (которая в теории может быть недостоверной)

count(*) [в MySQL] в отличие от иных описаний таблиц считает точно. Потому и медленно. Есть ряд других способов оценить число строк приблизительно, они — да, быстрые.

Покажи show create table на обеих и сами запросы.

Переход на полное сканирование таблицы может быть как-то завязан на присутствие или даже возможность присутствия NULL значений в полях

Все поля, что упомянуты в explain (и PRIMARY id, и бинарное is_deleted) идентичны — NULL там нет.

Вот что может быть, так это в индексе is_deleted, в принципе, может быть информация сколько записей «0», а сколько «1». И тогда COUNT(*) может быстро сложить эти значения. А в PRIMARY подобной информации может не быть.

Покажи show create table на обеих

Загадочный ЛОР (и выше он много сожрал):

Ой, блин, это еще и MariaDB. Если у вас innodb, почему Percona не взять?

Я же пишу — проблема очень давняя. На MySQL несколько лет назад было также. Там не было никаких революционных изменений.

Если у вас innodb, почему Percona не взять?

Так те же уши будут.

Не факт, они на innodb собаку давно жрут.

Я вижу в «медленной» констрейнт на «быструю», а в быстрой только на users. Учитывая что мы на колде тестируем — не может ли быть что он перед count перестраивает весь этот индекс (опять же, там каскад), грузит его в память и т.д., а уже потом быстро вам начинает все отдавать на горячем? Юзеров у вас вряд ли 4 ляма.

— это не ошибка? count(*) считает все строки, count(id) — те. в который id is not null, count(distinct id) — уникальные id. Они выполняются по разному и с разной скоростью.

Я почему спрашиваю, если вы в count пихаете какое-то поле, то в верхней таблице у вас куча индексов по ним, а в нижней — нету.

это не ошибка? count(X) считает все строки, count(id) — те. в который id is not null

Одинаково по скорости с count(id) (проверял), всё равно id NOT NULL.

(поменял звёздочку на X, чтобы ЛОР-парсер не жрал)

не может ли быть что он перед count перестраивает весь этот индекс

Сложно представить, зачем оно так реализовано в таком случае. Хотя, да, это единственная заметная разница.

Хм. Есть у меня ещё похожая таблица:

Тут нет foreign index’а. И тоже работает шустро. Так что, похоже, дело в нём, действительно.

Он, оказывается, работает не с модификацией при просмотре, а с модификацией перед отсылкой 😀

В MyISAM есть внутренний счетчик, в innodb нету, поэтому здесь count медленней

что-то сильно сомневаюсь что в foreign index дело.
И вообще планы выполнения запроса странные. В posts же есть первичный id, но используется is_deleted.
Попробуй вместо count(*) использовать count(id) . Також можно указать принудительно использовать index USE INDEX(id) . Также все измерения проводить с SQL_NO_CACHE, как в мариадб не знаю. Также попробуй рестартнуть сервер базы и выполнить сначала запросы на медленной табле, а потом на быстрой.

И вообще планы выполнения запроса странные. В posts же есть первичный id, но используется is_deleted.

Видимо, дело в том, что id имеет столько же значений элементов, сколько записей и длина поля индекса 4 байта, а в is_deleted — только два значения и длина поля 1 байт. Вероятно (я без понятия, как в MySQL устроены индексы) считать по второму случаю быстрее.

Попробуй вместо count(*) использовать count(id)

Никакой разницы. Кстати, план показывает тоже использование ключа is_deleted.

Також можно указать принудительно использовать index USE INDEX(id)

Вот, действительно, дело не в foreign index, а, как и предполагал сперва (но потом забылось), видимо, в размере индекса. USE INDEX(PRIMARY) в posts отрабатывает очень долго (ещё не завершён, но уже понятно, что длится минуты будет) и план показывает PRIMARY и 4 байта длину.

Также все измерения проводить с SQL_NO_CACHE

Это не актуально, сервер под большой нагрузкой и поэтому кеши вычищаются очень быстро, за считанные минуты 🙂

Также попробуй рестартнуть сервер базы

Там процесс перезапуска сервера длится десятки минут 🙂

и выполнить сначала запросы на медленной табле, а потом на быстрой.

Как писал раньше, проблема очень давняя, за это время сервер рестартовал много раз. И первым обращением были совершенно разные таблицы.

хм, раз такое дело, что влияет количество байт в индексе, может не хватает места для индексов
Какие параметры в конфигах?

Источник

Функция MySql COUNT () не работает

Я пытаюсь получить лучший постер блога из нашей базы данных mysql

В настоящее время это работает для его части:

Теперь мне нужно также зарегистрировать для них значок эскиза людей, поэтому я пробую это:

Имя пользователя, owner_id и storage_path верны, но каков подсчет db, поскольку это значение для Occurences неверно? Я думал, что, указав COUNT( engine4_blog_blogs . owner_id ) , будет учитываться только это поле — также я должен добавить, что поле столбца owner_id существует только в таблице engine4_blog_blogs.

Теперь я пробовал различные перестановки, включая СОЕДИНЕНИЯ, ВНУТРЕННИЕ СОЕДИНЕНИЯ и ЛЕВЫЕ СОЕДИНЕНИЯ, и все они дают один и тот же результат . Неверный count ().

В основном я ищу этот вывод:

Кто-нибудь знает, что я делаю не так (имейте в виду, что я не трогал sql более 10 лет)? Спасибо за любую помощь!

2 ответа

Чтобы группировка работала правильно . вы должны сгруппировать по всем неагрегированным столбцам:

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

Mysql поддерживает нестандартный синтаксис группировки — если вы будете придерживаться стандарта, он будет работать так, как вы ожидаете.

Я отправлю свой комментарий в качестве ответа.

Вы считаете owner_id. Но следует считать его посты. Итак, вместо

Предполагая, что blog_id является первичным ключом engine4_blog_blogs

Источник

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

Задавайте вопросы, мы ответим

Страниц: 1

#1 10.10.2013 16:09:57

select count() where, где count = 0

Не выводит записи, где count = 0. Группировка есть, где я не прав?

SELECT
catalogs.id,
COUNT (DISTINCT comments.id) AS comments
FROM catalogs
LEFT JOIN comments ON catalogs.id = comments.catalog
WHERE catalogs.removed = 0 AND comments.removed = 0
GROUP BY catalog.id
ORDER BY catalog.id

Отредактированно wine-time (10.10.2013 16:10:37)

#2 10.10.2013 16:58:02

Re: select count() where, где count = 0

Приведите пример с тестовыми данными на которых видна проблема.

#3 11.10.2013 10:13:31

Re: select count() where, где count = 0

Маленькая база с 2 таблицами здесь https://dl.dropboxusercontent.com/u/36526176/test.sql
Если будет лень экспортировать, то в первой таблице просто catalog;
а вторая выглядит так: https://dl.dropboxusercontent.com/u/365 … able_2.png

Я получаю:
id comments
1 1
2 1
4 1
6 3

Т.е. не выводит те, где подсчёт дал бы 0

Отредактированно wine-time (11.10.2013 10:15:46)

#4 11.10.2013 12:55:19

Re: select count() where, где count = 0

Так вы сами отсекаете их условием WHERE comments.removed = 0

Для наглядности выполните на тестовых значениях:

Возможно вам нужно:

#5 11.10.2013 13:04:29

Re: select count() where, где count = 0

Т.е. вместо условия на count, я поставил условие на всю выборку..
Спасибо вам большое.

#6 14.10.2013 11:33:51

Re: select count() where, где count = 0

UPD: простите, снова вопрос. прочитал про is null, обрадовался новым знаниям.
Вы были правы, мне нужный последний запрос,

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

SELECT
catalogs.id AS id,
COUNT(DISTINCT t.id) AS total,
COUNT(DISTINCT c.id) AS closed
FROM catalogs
LEFT JOIN comments t ON catalogs.id = t.catalog
LEFT JOIN comments c ON catalogs.id = c.catalog
WHERE catalogs.removed = 0
AND ( t.removed = 0 OR t.removed is NULL )
AND ( c.removed = 0 OR c.removed is NULL )
AND ( c.is_open = 0 OR c.removed is NULL )
GROUP BY catalogs.id
ORDER BY catalogs.id;

Но такой запрос отдаёт те, где:
• вообще нет comments (т.е. найдено 0)
• есть хотя бы 1, где comments.is_open = 0

Из выдачи убраны те каталоги, где подсчёт дал больше нуля, но среди них нет удовлетворяющего c.is_open = 0
Что я упустил?

Отредактированно wine-time (14.10.2013 11:40:48)

Источник