一文了解MySQL的MySQL的聚合函数使用

☃️0. 前置

为了方便测试，我们导入一些数据

SET NAMES utf8mb4;
SET FOREIGN_KEY_CHECKS = 0;

-- ----------------------------
-- Table structure for procatch_work_om_sp_type
-- ----------------------------
DROP TABLE IF EXISTS `procatch_work_om_sp_type`;
CREATE TABLE `procatch_work_om_sp_type`  (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键id',
  `sp_type_name` varchar(15) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT '备件类型名称',
  `sp_type_parent_id` bigint(20) NOT NULL DEFAULT 0 COMMENT '父类类型id 没有就是0',
  `current_level` tinyint(3) UNSIGNED NOT NULL COMMENT '当前层级（1/2/3）',
  `sp_num` int(10) UNSIGNED NOT NULL DEFAULT 0 COMMENT '该备件类型下的备件数量（只是该备件类型下,不算类型父级）',
  `create_time` datetime(0) DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 1661945101694476291 CHARACTER SET = utf8 COLLATE = utf8_general_ci COMMENT = '运维-备件-备件类型' ROW_FORMAT = Dynamic;

-- ----------------------------
-- Records of procatch_work_om_sp_type
-- ----------------------------
INSERT INTO `procatch_work_om_sp_type` VALUES (1647810442107748353, '五金', 0, 1, 0, '2023-04-17 11:53:18');
INSERT INTO `procatch_work_om_sp_type` VALUES (1647810699784814593, '通用五金配件', 1647810442107748353, 2, 1, '2023-04-17 11:54:20');
INSERT INTO `procatch_work_om_sp_type` VALUES (1647810699793203202, '装饰五金配件', 1647810442107748353, 2, 21, '2023-04-17 11:54:20');
INSERT INTO `procatch_work_om_sp_type` VALUES (1647810699797397506, '五金冲压配件', 1647810442107748353, 2, 0, '2023-04-17 11:54:20');
INSERT INTO `procatch_work_om_sp_type` VALUES (1647810699805786113, '相框五金配件', 1647810442107748353, 2, 0, '2023-04-17 11:54:20');
INSERT INTO `procatch_work_om_sp_type` VALUES (1647810699814174722, '门窗五金配件', 1647810442107748353, 2, 0, '2023-04-17 11:54:20');
INSERT INTO `procatch_work_om_sp_type` VALUES (1648249529373491202, '铣床', 0, 1, 0, '2023-04-18 16:58:05');
INSERT INTO `procatch_work_om_sp_type` VALUES (1648249529377685506, '机床', 0, 1, 8, '2023-04-18 16:58:05');
INSERT INTO `procatch_work_om_sp_type` VALUES (1648249529381879810, '钻床', 0, 1, 0, '2023-04-18 16:58:05');

数据如下

☃️1. 聚合函数介绍

什么是聚合函数

聚合函数作用于一组数据，并对一组数据返回一个值。

聚合函数类型

• AVG() 求平均值
• SUM() 求和
• MAX() 求最大值
• MIN() 求最小值
• COUNT() 求总行数

聚合函数语法

SELECT SUM(某字段) FROM TABLE_NAME WHERE ...

聚合函数不能嵌套调用。比如不能出现类似“AVG(SUM(字段名称))”形式的调用。

❄️❄️1.1 AVG 和 SUM 函数

可以对数值型数据使用 AVG 和 SUM 函数。

AVG 比如我们求案例表的全部备件类型下的备件数量的平均值

SELECT AVG(sp_num) FROM `procatch_work_om_sp_type`

结果如下：

SUM 比如我们求案例表的全部备件类型下的备件数量的和

SELECT SUM(sp_num) FROM `procatch_work_om_sp_type`

结果如下：

❄️❄️1.2 MIN 和 MAX 函数

可以对任意数据类型的数据使用 MIN 和 MAX 函数。

比如我们求案例表的全部备件类型下的备件数量的最小值、最大值

SELECT MIN(sp_num),MAX(sp_num) FROM `procatch_work_om_sp_type`

结果如下：

❄️❄️1.3 COUNT函数

COUNT(*) 返回表中记录总数，适用于任意数据类型。

COUNT(expr) 返回expr不为空的记录总数。

比如我们有如下这张表：

执行如下语句

SELECT COUNT(*), COUNT(name) FROM `agreement_file`

得到结果：分别为 46 个 29

COUNT(*) 返回表中记录总数 ：46 。
COUNT(name) 返回 name 不为空的记录总数 ：29。

问题：用count(*)，count(1)，count(列名)谁好呢?

- 其实，对于MyISAM引擎的表是没有区别的。这种引擎内部有一计数器在维护着行数。
- Innodb引擎的表用count(*),count(1)直接读行数，复杂度是O(n)，因为innodb真的要去数一遍。
但好于具体的count(列名)。

问题：能不能使用count(列名)替换count(*)?

- 不要使用 count(列名)来替代 count(*) ， count(*) 是 SQL92 定义的标准统计行数的语法，跟数
据库无关，跟 NULL 和非 NULL 无关。
- 说明：count(*)会统计值为 NULL 的行，而 count(列名)不会统计此列为 NULL 值的行。

---

☃️2. GROUP BY

❄️❄️2.1 基本使用

有如下一张表：

可以使用GROUP BY 语句将表中的数据分成若干组 展示每个备件类型的个数

SELECT spare_part_type_id, SUM(1) 
FROM `procatch_work_om_spare_part` 
GROUP BY spare_part_type_id

---

☃️3. HAVING

❄️❄️3.1 基本使用

过滤分组：HAVING子句
1. 行已经被分组。
2. 使用了聚合函数。
3. 满足HAVING 子句中条件的分组将被显示。
4. HAVING 不建议单独使用，建议只和 GROUP BY 一起使用。

注意：不能在 WHERE 子句中使用聚合函数

❄️❄️3.2 WHERE和HAVING的对比

区别1：WHERE 可以直接使用表中的字段作为筛选条件，但不能使用分组中的计算函数作为筛选条件；HAVING 必须要与 GROUP BY 配合使用，可以把分组计算的函数和分组字段作为筛选条件。这决定了，在需要对数据进行分组统计的时候，HAVING 可以完成 WHERE 不能完成的任务。这是因为，在查询语法结构中，WHERE 在 GROUP BY 之前，所以无法对分组结果进行筛选。HAVING 在GROUP BY 之后，可以使用分组字段和分组中的计算函数，对分组的结果集进行筛选，这个功能是WHERE 无法完成的。另外，WHERE排除的记录不再包括在分组中。

区别2：如果需要通过连接从关联表中获取需要的数据，WHERE 是先筛选后连接，而 HAVING 是先连接后筛选。 这一点，就决定了在关联查询中，WHERE 比 HAVING 更高效。因为 WHERE 可以先筛选，用一个筛选后的较小数据集和关联表进行连接，这样占用的资源比较少，执行效率也比较高。HAVING则需要先把结果集准备好，也就是用未被筛选的数据集进行关联，然后对这个大的数据集进行筛选，这样占用的资源就比较多，执行效率也较低。

小结如下：

	优点	缺点
WHERE	先筛选数据再关联，执行效率高	不能使用分组中的计算函数进行筛选
HAVING	可以使用分组中的计算函数	在最后的结果集中进行筛选，执行效率较低

开发中的选择：
WHERE 和 HAVING 也不是互相排斥的，我们可以在一个查询里面同时使用 WHERE 和 HAVING。包含分组统计函数的条件用 HAVING，普通条件用 WHERE。这样，我们就既利用了 WHERE 条件的高效快速，又发挥了 HAVING 可以使用包含分组统计函数的查询条件的优点。当数据量特别大的时候，运行效率会有很大的差别。