- SQL — Урок 8. Группировка записей и функция COUNT()
- Видеоуроки php + mysql
- Функция COUNT
- Основные запросы
- Условия выборки
- Группировка
- Сложение строк
- Несколько таблиц
- Длина строк
- Изменение строк
- Поиск по строкам
- Работа с пробелами
- Работа с регистром
- Информация
- Условия
- Полезное
- Разное
- Математические функции
- Списки
- Извлечение части даты
- Получение даты и времени
- Преобразование даты
- Сложение дат
- Тригонометрия
- Отдельные символы
- Системы счисления
- Синтаксис
- Примеры
- Пример
- Пример
- Пример
- Меняем таблицу для примеров
- Пример
- COUNT(*)
- Oracle PL/SQL •MySQL •MariaDB •SQL Server •SQLite
- Базы данных
- SQL функция COUNT
- Описание
- Синтаксис
- Параметры или аргумент
- Пример — функция COUNT включает только значения NOT NUL
SQL — Урок 8. Группировка записей и функция COUNT()
Давайте вспомним, какие сообщения и в каких темах у нас имеются. Для этого можно воспользоваться привычным запросом:
А что, если нам надо лишь узнать сколько сообщений на форуме имеется. Для этого можно воспользоваться встроенной функцией COUNT(). Эта функция подсчитывает число строк. Причем, если в качестве аргумента этой функции выступает *, то подсчитываются все строки таблицы. А если в качестве аргумента указывается имя столбца, то подсчитываются только те строки, которые имеют значение в указанном столбце.
В нашем примере оба аргумента дадут одинаковый результат, т.к. все столбцы таблицы имеют тип NOT NULL. Давайте напишем запрос, используя в качестве аргумента столбец id_topic:
Итак, в наших темах имеется 4 сообщения. Но что, если мы хотим узнать сколько сообщений имеется в каждой теме. Для этого нам понадобится сгруппировать наши сообщения по темам и вычислить для каждой группы количество сообщений. Для группировки в SQL используется оператор GROUP BY. Наш запрос теперь будет выглядеть так:
Оператор GROUP BY указывает СУБД сгруппировать данные по столбцу id_topic (т.е. каждая тема — отдельная группа) и для каждой группы подсчитать количество строк:
Ну вот, в теме с у нас 3 сообщения, а с — одно. Кстати, если бы в поле id_topic были возможны отсутствия значений, то такие строки были бы объединены в отдельную группу со значением NULL.
Предположим, что нас интересуют только те группы, в которых больше двух сообщений. В обычном запросе мы указали бы условие с помощью оператора WHERE, но этот оператор умеет работать только со строками, а для групп те же функции выполняет оператор HAVING:
В результате имеем:
В уроке 4 мы рассматривали, какие условия можно задавать оператором WHERE, те же условия можно задавать и оператором HAVING, только надо запомнить, что WHERE фильтрует строки, а HAVING — группы.
Итак, сегодня мы узнали, как создавать группы и как подсчитать количество строк в таблице и в группах. Вообще вместе с оператором GROUP BY можно использовать и другие встроенные функции, но их мы будем изучать позже.
Видеоуроки php + mysql
Если этот сайт оказался вам полезен, пожалуйста, посмотрите другие наши статьи и разделы.
Источник
Функция COUNT
Основные запросы
Условия выборки
Группировка
Сложение строк
Несколько таблиц
Длина строк
Изменение строк
Поиск по строкам
Работа с пробелами
Работа с регистром
Информация
Условия
Полезное
Разное
- Типы полей
- Организация базы данных
создание правильной структуры —> - Подзапросы
- SELECT @min_price:=MIN(price),@max_price:=MAX(price) FROM shop; mysql> SELECT * FROM shop WHERE price=@min_price OR price=@max_price; https://habrahabr.ru/post/133781/ тут еще про переменные цикл получается SET @i = 0; SELECT * FROM product WHERE MOD(@i:=@i+1, 2) = 0; —>Переменные sql
Математические функции
Списки
Извлечение части даты
Получение даты и времени
Преобразование даты
Сложение дат
Тригонометрия
Отдельные символы
Системы счисления
Функция COUNT подсчитывает количество записей в таблице.
Условие, по которому будут выбираться записи, задается с помощью команды WHERE.
Команда WHERE не является обязательной, если ее не указать — будут подсчитаны все записи в таблице.
См. также команду DISTINCT, которая позволяет подсчитывать только уникальные значения поля.
См. также команду GROUP BY, которая позволяет группировать записи и затем с помощью COUNT подсчитывать количество в группах.
Синтаксис
Подсчет всех записей:
Подсчет всех записей, где заданное поле не равно NULL:
Только уникальные значения поля:
Примеры
Все примеры будут по этой таблице workers, если не сказано иное:
id айди | name имя | age возраст | salary зарплата |
---|---|---|---|
1 | Дима | 23 | 400 |
2 | Петя | 25 | 500 |
3 | Вася | 23 | 500 |
4 | Коля | 30 | 1000 |
5 | Иван | 27 | 500 |
6 | Кирилл | 28 | 1000 |
Пример
Давайте подсчитаем всех работников с возрастом 23 года:
Результат выполнения SQL запроса:
count результат подсчета |
---|
2 |
Пример
Давайте подсчитаем количество разных зарплат (их будет 3 штуки: 400, 500 и 1000):
Результат выполнения SQL запроса:
count результат подсчета |
---|
3 |
Пример
Давайте подсчитаем одновременно количество разных возрастов и количество разных зарплат:
Результат выполнения SQL запроса:
count1 количество возрастов | count2 количество зарплат |
---|---|
5 | 3 |
Меняем таблицу для примеров
Все примеры ниже будут по этой таблице workers, если не сказано иное:
id айди | name имя | age возраст | salary зарплата |
---|---|---|---|
1 | Дима | 23 | NULL |
2 | Петя | 25 | 500 |
3 | Вася | 23 | NULL |
Пример
Давайте подсчитаем количество всех записей:
Результат выполнения SQL запроса:
count результат подсчета |
---|
3 |
А теперь подсчитаем количество зарплат, не равных NULL:
Источник
COUNT(*)
У меня есть подборка простеньких вопросов, которые я люблю задавать при собеседовании. Например, как посчитать общее число записей к таблице? Вроде бы ничего сложного, но если копнуть глубже, то можно много интересных нюансов рассказать собеседнику.
Давайте начнем с простого… Эти запросы отличаются чем-то друг от друга с точки зрения конечного результата?
Большинство отвечали: «Нет».
Реже старались долее детально формировать ответ: «Запросы вернут идентичный результат, но COUNT вернет значение типа INT, а COUNT_BIG – тип BIGINT».
Если проанализировать план выполнения, то можно заметить различия, которые многие упускают из вида. При использовании COUNT на плане будет операция Compute Scalar:
Если посмотреть в свойства оператора, то мы увидим там:
Это происходит потому, что при вызове COUNT неявно используется COUNT_BIG после чего результат преобразуется в INT.
Не сказал бы, что существенно, но преобразования типов увеличивает нагрузку на процессор. Многие, конечно, могут сказать, что этот оператор ничего не стоит при выполнении, но нужно отметить простой факт – SQL Server очень часто недооценивает Compute Scalar операторы.
Еще я знаю людей, которые любят использовать SUM вместо COUNT:
Такой вариант примерно равнозначен COUNT. Мы также получим лишний Compute Scalar на плане выполнения:
Теперь более детально затронем вопросы производительности.…
Если использовать запросы выше, то чтобы посчитать количество записей SQL Server необходимо выполнить Full Index Scan (или Full Table Scan если таблица является кучей). В любом случае, эти операции далеко не самые быстрые. Лучше всего для получения количества записей использовать системные представления: sys.dm_db_partition_stats или sys.partitions (есть еще sysindexes, но оставлен для обратной совместимости с SQL Server 2000).
Если сравнить планы выполнения, то доступ к системным представлениям менее затратный:
На AdventureWorks преимущество от применения системных представлений явно не проявляется:
Время выполнения на секционированной таблице с 30 миллионами записей:
В случае если нужно проверить наличие записей в таблице, то использование метаданных как было показано выше не даст особых преимуществ…
И на практике будет даже капельку медленнее, поскольку SQL Server генерирует более сложный план выполнения для выборки из метаданных.
Еще интереснее становиться, когда нужно посчитать количество записей по всем таблицам сразу. На практике встречал несколько вариантов, которые можно обобщить.
Вариант #1 с применением недокументированной процедуры, которая курсором обходит все пользовательские таблицы:
Вариант #2 – динамический SQL которые генерирует запросы SELECT COUNT(*):
Вариант #3 – быстрый вариант на каждый день:
Уж очень много я выдал дифирамбов, что системные представления такие хорошие. Однако, при работе с ними нас могут подстерегать «приятные» неожиданности.
Помнится, был такой веселый баг, когда при миграции с SQL Server 2000 на 2005 некоторые системные представления некорректно обновлялись. Особо везучим людям, в таком случае, из метаданных возвращались неверные значения о количестве записей в таблицах. Лечилось это все командой DBCC UPDATEUSAGE.
Вместе с SQL Server 2005 SP1 этот баг исправили и все бы ничего… Но подобную ситуацию я наблюдал еще один раз, когда восстановил бекап с SQL Server 2005 SP4 на SQL Server 2012 SP2. Воспроизвести проблему на реальном окружении увы не смогу, поэтому немного обманув оптимизатор:
расскажу на простом примере.
Самый безобидный запрос начал выполняться дольше чем обычно:
Посмотрел на план запроса и увидел там явно неадекватное значение Estimated number of rows:
Заглянул в статистику по кластерному индексу:
Все было в норме:
Но в системных представления о которых мы говорили ранее:
В запросе не было предикатов для фильтрации и оптимизатор выбрал Full Index Scan. При Full Index/Table Scan ожидаемое количество строк оптимизатор не берет из статистики, а обращается к метаданным (точно не уверен всегда ли это происходит).
Не секрет, что на основе Estimated number of rows SQL Server генерирует план выполнения и вычисляет сколько нужно памяти чтобы его выполнить. Если оценка будет неверной, то может быть выделено больше памяти на выполнение запроса, чем нужно на самом деле.
Вот к чему приводит неверная оценка количества строк:
Проблема решилась достаточно просто:
После рекомпиляции запроса все пришло в норму:
Если системные представления уже не кажутся «спасительной палочкой», то какие варианты у нас остаются? Можно делать все по-старинке:
Но при интенсивной вставке в таблицу я бы не доверял результатам. «Волшебный» хинт NOLOCK тем более не гарантирует правильного значения:
По сути, чтобы получить правильное значение количества строк в таблице, нужно выполнять запрос под уровнем изоляции SERIALIZABLE либо используя хинт TABLOCKX:
И что мы получаем в итоге… монопольную блокировку таблицы на период выполнении запроса. И тут каждый должен решать сам, что ему лучше использовать. Мой выбор — метаданные.
Еще интереснее, когда нужно быстро подсчитать число строк по условию:
Если в таблице не происходят частые операции вставки-удаления, то можно создать индексированное представление:
Для этих запросов оптимизатор будет генерировать идентичный план на основе кластерного индекса вьюхи:
План выполнения с индексным представлением и без:
Этим постом я хотел показать, что идеальных решений на все случаи жизни не бывает. И в каждом конкретной ситуации нужно действовать с индивидуальным подходом.
Все тестировалось на SQL Server 2012 SP3 (11.00.6020).
В качестве выводов… Когда нужно подсчитать общее число строк по таблице, то я использую метаданные — это самый быстрый способ. И пусть Вас не пугает ситуация с старым багом, который я привел выше.
Если нужно быстро подсчитать количество строк в разрезе какого-то поля или по условию — то я стараюсь использовать индексированные представления либо фильтрованные индексы. Все зависит от ситуации.
Когда таблица маленькая или вопросы с производительностью не стоят так остро, то проще уж действительно по-старинке написать SELECT COUNT(*)…
Если хотите поделиться этой статьей с англоязычной аудиторией:
What is the fastest way to calculate the record COUNT?
Источник
Oracle PL/SQL •MySQL •MariaDB •SQL Server •SQLite
Базы данных
SQL функция COUNT
В этом учебном материале вы узнаете, как использовать SQL функцию COUNT с синтаксисом и примерами.
Описание
SQL функция COUNT используется для подсчета количества строк, возвращаемых в операторе SELECT.
Синтаксис
Синтаксис для функции COUNT в SQL.
Или синтаксис для функции COUNT при группировке результатов по одному или нескольким столбцам.
Параметры или аргумент
Пример — функция COUNT включает только значения NOT NUL
Не все это понимают, но функция COUNT будет подсчитывать только те записи, в которых expressions НЕ равно NULL в COUNT( expressions ). Когда expressions является значением NULL, оно не включается в вычисления COUNT. Давайте рассмотрим это дальше.
В этом примере у нас есть таблица customers со следующими данными:
customer_id | first_name | last_name | favorite_website |
---|---|---|---|
4000 | Justin | Bieber | google.com |
5000 | Selena | Gomez | bing.com |
6000 | Mila | Kunis | yahoo.com |
7000 | Tom | Cruise | oracle.com |
8000 | Johnny | Depp | NULL |
9000 | Russell | Crowe | google.com |
Введите следующий запрос SELECT, которая использует функцию COUNT.
Источник