原创

**count(1)、count(*) 与 count(列名) 的区别详解**

发布时间：2026-03-12 21:28:15
本文热度：浏览 10 赞 0 评论 0
文章标签： SQL MySQL 数据库
全文共1字，阅读约需1分钟

一、为什么这个问题总被反复讨论

在日常开发中，count(1)、count(*) 和 count(列名) 几乎是每个后端工程师都会写到的 SQL。它们看起来非常相似，甚至很多项目代码里三种写法混用，但一旦进入性能分析、SQL 审查、慢查询优化、数据库迁移或团队规范制定阶段，这个问题就会被反复拿出来讨论。

讨论之所以经久不衰，原因并不复杂：第一，它们的语义并不完全相同；第二，不同数据库内核对它们的优化策略不完全一样；第三，很多“经验结论”来源于早期版本、特定存储引擎或者误传，放到今天的生产环境里已经不成立；第四，一旦和 NULL、索引、执行计划、存储引擎实现方式结合起来，表面上简单的 count 就会变成一个足以影响系统性能和结果正确性的问题。

如果只给结论，那么可以先记住这一句：

count(*)：统计结果集中的总行数，不忽略任何行
count(1)：统计结果集中的总行数，本质上也是不忽略任何行
count(列名)：统计结果集中 该列不为 NULL 的行数

真正重要的不是记住这三句话，而是理解它们在语义、执行机制、优化器行为和工程实践中的区别。只有理解到这个层面，才能在复杂 SQL、分页统计、报表聚合、联表查询、索引设计和 SQL 规范制定时做出正确选择。

二、先从 SQL 标准语义说起

2.1 聚合函数 `COUNT` 的基本定义

COUNT 是 SQL 标准中的聚合函数，用于对结果集进行计数。其常见形式包括：

COUNT(*)
COUNT(expr)
COUNT(DISTINCT expr)

其中：

COUNT(*) 统计分组后每个组中的总行数
COUNT(expr) 统计分组后每个组中 expr 结果不为 NULL 的行数
COUNT(DISTINCT expr) 统计分组后每个组中 expr 去重且不为 NULL 的值个数

这意味着 COUNT 的核心区别并不是写法风格，而是 聚合对象是什么。

2.2 为什么 `count(1)` 和 `count(*)` 常被认为一样

因为 1 是一个常量表达式。对于每一行来说，表达式 1 的值永远是 1，不可能是 NULL。所以：

COUNT(1)

等价于对每一行都提供一个恒不为 NULL 的表达式，再统计非 NULL 的个数。既然每一行都不是 NULL，那最终统计结果就等于总行数。

因此在结果语义上，count(1) 和 count(*) 一致。

2.3 为什么 `count(列名)` 不一样

因为列值可能为 NULL。例如：

COUNT(email)

只会统计 email IS NOT NULL 的行数，而不是整张表的总行数。

这也是很多线上统计口径错误的根源：开发者把 count(列名) 当成了总数统计，结果因为字段允许空值，统计结果偏小，导致报表、分页总数、数据核对全部出现偏差。

三、通过一个完整示例理解三者区别

先准备一张测试表。

3.1 建表 SQL

DROP TABLE IF EXISTS user_account;

CREATE TABLE user_account (
    id BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键ID',
    username VARCHAR(64) NOT NULL COMMENT '用户名',
    email VARCHAR(128) DEFAULT NULL COMMENT '邮箱，允许为空',
    phone VARCHAR(32) DEFAULT NULL COMMENT '手机号，允许为空',
    status TINYINT NOT NULL DEFAULT 1 COMMENT '状态：1启用，0禁用',
    created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
    PRIMARY KEY (id),
    KEY idx_status (status),
    KEY idx_email (email)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户账户表';

插入测试数据：

INSERT INTO user_account (username, email, phone, status) VALUES
('alice', 'alice@example.com', '13800000001', 1),
('bob', NULL, '13800000002', 1),
('charlie', 'charlie@example.com', NULL, 0),
('david', NULL, NULL, 1),
('eric', 'eric@example.com', '13800000005', 1);

当前表中共有 5 行数据，其中：

email 不为 NULL 的有 3 行
phone 不为 NULL 的有 3 行
总记录数为 5

3.2 执行不同 SQL

SELECT COUNT(*) FROM user_account;

结果：

SELECT COUNT(1) FROM user_account;

结果：

SELECT COUNT(email) FROM user_account;

结果：

SELECT COUNT(phone) FROM user_account;

结果：

这个例子已经足够说明最核心的问题： count(*) 与 count(1) 统计的是行数；count(列名) 统计的是该列非空值的数量。

四、从执行逻辑上看三者到底做了什么

4.1 `count(*)` 的逻辑含义

count(*) 的 * 并不是“把所有列取出来逐个判断”的意思。这里的 * 代表的是 当前结果集的每一行。它并不关心列值是什么，也不关心某些列是否为 NULL。

可以把它理解成：

对结果集中的每一行都计数 1 次。

所以它统计的是“行的数量”，而不是“列值的数量”。

4.2 `count(1)` 的逻辑含义

count(1) 可以理解成：

对结果集中的每一行，先计算表达式 1，然后统计该表达式不为 NULL 的行数。

由于常量 1 永远不为 NULL，所以每一行都会被计数，最终结果与总行数一致。

从语义上说，它更接近 count(表达式)，只是表达式恰好永远不为 NULL。

4.3 `count(列名)` 的逻辑含义

count(列名) 则是：

对结果集中的每一行，取该列的值；如果值不为 NULL，计数加 1；如果值为 NULL，跳过。

因此它统计的是“该列存在值的记录数”，不是“结果集中的总行数”。

五、最容易出错的地方：`NULL` 对统计结果的影响

5.1 `count(*)` 不受 `NULL` 影响

无论一行里有多少列是 NULL，只要这行存在，并且被 WHERE 条件筛选进结果集，count(*) 就会计数。

例如：

SELECT COUNT(*) FROM user_account WHERE status = 1;

假设 status=1 的记录有 4 条，即使这 4 条中 email、phone 都有空值，结果仍然是 4。

5.2 `count(列名)` 会受 `NULL` 影响

SELECT COUNT(email) FROM user_account WHERE status = 1;

这条 SQL 统计的是 status=1 且 email 不为 NULL 的记录数。

如果你原本想统计启用用户总数，却误写成 count(email)，而恰好一部分用户邮箱为空，那么结果就会偏小。

5.3 一个典型误用示例

错误写法：

SELECT COUNT(update_time) FROM orders WHERE order_status = 'PAID';

如果 update_time 存在历史脏数据为空，或者业务上某些记录尚未更新，那么这条 SQL 统计出来的就不是“已支付订单总数”，而是“已支付且 update_time 不为空的订单数”。

正确写法应该是：

SELECT COUNT(*) FROM orders WHERE order_status = 'PAID';

除非你的业务需求本身就是要统计“update_time 已填写的已支付订单数”。

六、在 `WHERE`、`GROUP BY`、`LEFT JOIN` 中区别会更加明显

很多人对单表 count 没问题，但一旦遇到分组、左连接、明细聚合就容易写错。真正的复杂性往往出现在这里。

七、`WHERE` 条件下的表现

先看一个简单例子：

SELECT COUNT(*) FROM user_account WHERE status = 1;
SELECT COUNT(1) FROM user_account WHERE status = 1;
SELECT COUNT(email) FROM user_account WHERE status = 1;

假设 status=1 的行有 4 条，其中 email 不为空的有 2 条，那么结果分别是：

count(*) = 4
count(1) = 4
count(email) = 2

WHERE 是先过滤行，再交给聚合函数处理。因此：

count(*) 统计过滤后的总行数
count(1) 统计过滤后表达式不为 NULL 的行数，这里仍然是总行数
count(列名) 统计过滤后该列不为 NULL 的行数

这个顺序一定要清楚，否则很容易误判。

八、`GROUP BY` 场景下的区别

8.1 分组统计示例

SELECT
    status,
    COUNT(*) AS total_count,
    COUNT(email) AS email_count
FROM user_account
GROUP BY status;

这条 SQL 的含义是：

按 status 分组
total_count：每组中的总记录数
email_count：每组中 email 不为空的记录数

假设结果是：

status	total_count	email_count
0	1	1
1	4	2

这个结果非常有价值，因为它同时表达了两个维度：

状态为 1 的用户一共有 4 个
但其中只有 2 个填写了邮箱

这里 count(email) 不是错误，它恰恰是在表达“字段覆盖率”或“有效值数量”。

8.2 `count(列名)` 在分组统计中的合理用途

在很多报表类需求里，count(列名) 是非常合适的，比如：

统计每个部门已填写手机号的人数
统计每个城市已实名认证用户数（某字段不为空）
统计每个商品类目中已上架图片的商品数量
统计每个业务分区中存在回执时间的工单数量

这时候 count(列名) 表达的是“某个字段具备有效值的记录数”，语义非常清晰。

九、`LEFT JOIN` 场景是误用高发区

这是最容易踩坑的场景之一。

9.1 准备两张表

DROP TABLE IF EXISTS dept;
DROP TABLE IF EXISTS employee;

CREATE TABLE dept (
    id BIGINT NOT NULL AUTO_INCREMENT COMMENT '部门ID',
    dept_name VARCHAR(64) NOT NULL COMMENT '部门名称',
    PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='部门表';

CREATE TABLE employee (
    id BIGINT NOT NULL AUTO_INCREMENT COMMENT '员工ID',
    dept_id BIGINT NOT NULL COMMENT '部门ID',
    emp_name VARCHAR(64) NOT NULL COMMENT '员工姓名',
    PRIMARY KEY (id),
    KEY idx_dept_id (dept_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='员工表';

插入数据：

INSERT INTO dept (dept_name) VALUES
('研发部'),
('测试部'),
('运维部');

INSERT INTO employee (dept_id, emp_name) VALUES
(1, '张三'),
(1, '李四'),
(2, '王五');

此时：

研发部有 2 人
测试部有 1 人
运维部有 0 人

9.2 错误写法：`count(*)`

SELECT
    d.id,
    d.dept_name,
    COUNT(*) AS emp_count
FROM dept d
LEFT JOIN employee e ON d.id = e.dept_id
GROUP BY d.id, d.dept_name;

很多人以为这样就能统计各部门人数，实际上不完全正确。

因为 LEFT JOIN 会保留左表所有记录。对于“运维部”这种没有匹配员工的部门，也会产生一行结果，只是 employee 表相关列都是 NULL。于是 count(*) 会把这行也算进去。

结果会变成：

dept_name	emp_count
研发部	2
测试部	1
运维部	1

显然，运维部应该是 0，不应该是 1。

9.3 正确写法：统计右表主键或非空列

SELECT
    d.id,
    d.dept_name,
    COUNT(e.id) AS emp_count
FROM dept d
LEFT JOIN employee e ON d.id = e.dept_id
GROUP BY d.id, d.dept_name;

结果才是：

dept_name	emp_count
研发部	2
测试部	1
运维部	0

原因在于：

LEFT JOIN 后，运维部那一行中 e.id 为 NULL
count(e.id) 只统计非 NULL 值
所以运维部人数正确地统计为 0

9.4 这个结论非常重要

在 LEFT JOIN 统计“右表匹配数量”时：

count(*) 统计的是左连接结果集中的行数
count(右表主键) 统计的是右表真正匹配成功的记录数

因此在左连接场景下，两者语义完全不同，绝不能混用。

十、性能层面：`count(*)` 和 `count(1)` 到底谁更快

这是争论最多、误解也最多的问题。

10.1 结论先说

在现代主流数据库，尤其是 MySQL 的较新版本中，对于绝大多数场景，count(*) 与 count(1) 性能没有本质差别。很多情况下，优化器会把它们转换为等价的执行方式。

也就是说：

不要指望把 count(*) 改成 count(1) 就能明显提速
真正影响性能的，通常是 WHERE 条件、是否命中索引、是否需要回表、存储引擎特性、数据分布、统计信息、MVCC 可见性判断等因素

10.2 为什么坊间会流传“`count(1)` 比 `count(*)` 快”

主要有几个来源：

第一，早期数据库版本或特定实现差异

一些旧版本数据库优化能力较弱，可能对 count(*) 和 count(常量) 的实现不完全一致，从而出现微小差异。

第二，把语义理解和物理执行混在一起

有人误以为 count(*) 会“把所有列都取出来再计数”，这在现代数据库里是错误理解。* 在这里不是“展开所有列值逐个判断”。

第三，来自局部测试的误导

如果测试环境中缓存命中情况不同、执行计划不同、数据量较小，可能出现偶然波动，但这并不构成通用结论。

第四，口口相传造成经验失真

很多“优化建议”其实早就过时，但由于传播成本低，反而在面试题、博客和团队口径中长期存在。

10.3 为什么很多时候反而推荐 `count(*)`

因为它的语义最直接、最标准、最清晰：

你要统计总行数，就写 count(*)
任何阅读 SQL 的人都能立刻明白你的意图
数据库优化器也能明确识别这种语义

相比之下，count(1) 虽然通常结果一样，但它更像是一种“习惯写法”，而不是最准确表达意图的写法。

工程实践里，可读性和语义明确性通常比微乎其微且不稳定的性能差异更重要。

十一、MySQL 中的真实情况：不能脱离存储引擎谈 `count`

讨论 MySQL 时，必须区分存储引擎。不同存储引擎对行数统计的处理方式并不一样。

11.1 MyISAM 与 InnoDB 的重要区别

MyISAM

MyISAM 会维护表的精确行数，因此对于：

SELECT COUNT(*) FROM table_name;

如果没有 WHERE 条件，通常可以非常快地直接返回结果。

InnoDB

InnoDB 不维护一个可在所有事务隔离场景下直接复用的精确总行数。原因是 InnoDB 支持事务和 MVCC，不同事务看到的可见数据可能不同，因此“总行数”并不是一个对所有会话都恒定且可直接复用的值。

所以在 InnoDB 中执行：

SELECT COUNT(*) FROM table_name;

通常仍然需要扫描索引或数据来完成统计，而不是像 MyISAM 那样直接取元数据。

11.2 为什么 InnoDB 不能简单维护一个全局精确总数

因为事务隔离下，不同事务看到的数据快照不同。例如：

事务 A 插入了一条记录但未提交
事务 B 在可重复读或读已提交场景下，未必能看到这条记录
如果数据库只维护一个全局“当前总行数”，就无法满足每个事务的一致性视图要求

因此，InnoDB 的 count(*) 需要结合当前事务可见性来统计，这是它慢于 MyISAM 的根本原因之一。

11.3 版本差异要明确说明

这里必须明确：

“count(*) 在 MySQL 中很快”这个说法，不能脱离存储引擎
对 MyISAM 来说，无条件 count(*) 确实可能非常快
对 InnoDB 来说，无条件 count(*) 往往仍然要扫描
在现代生产环境中，MySQL 绝大多数业务表都使用 InnoDB
因此讨论线上性能时，应以 InnoDB 的行为 为主，而不是拿 MyISAM 的特性做普遍结论

十二、MySQL 优化器会如何处理 `count(*)`

12.1 可能选择更小的二级索引扫描

对于 InnoDB，如果执行：

SELECT COUNT(*) FROM user_account;

优化器可能会选择扫描一个更小的二级索引，而不是聚簇索引。原因很简单：统计行数不需要取出整行内容，只需要遍历足够代表每条记录的一组索引项即可。哪个索引页更小、扫描代价更低，就更可能被选择。

这也是为什么有时候你会发现：

表有多个索引
count(*) 的执行计划并不一定走主键
优化器会倾向于选“最便宜”的访问路径

12.2 `count(列名)` 可能影响可选索引

如果写成：

SELECT COUNT(email) FROM user_account;

那么数据库需要确保统计的是 email 非空值的数量。此时，如果 email 列上有索引，并且执行计划能够利用索引完成统计，可能效率也不错；但如果列没有索引、或者查询条件导致必须回表判断，则代价可能上升。

所以真正影响性能的不是“写了 1 还是 *”，而是：

是否存在可用索引
是否能通过索引直接完成统计
是否需要回表
是否有复杂过滤条件
数据分布是否导致执行计划失真

十三、`count(主键)` 能不能代替 `count(*)`

很多团队喜欢写：

SELECT COUNT(id) FROM table_name;

如果 id 是主键且定义为 NOT NULL，从结果上看，它通常等价于 count(*)。因为主键不可能为 NULL。

但是从工程规范角度看，仍然不建议把它当成统计总数的默认写法，原因有三点。

13.1 语义不如 `count(*)` 直接

count(*) 明确表示“统计总行数”。 count(id) 表示“统计 id 非空的记录数”。虽然在主键场景下两者结果一致，但表达意图不如 count(*) 直接。

13.2 容易在复制习惯时产生误用

开发者如果形成“总数就写 count(某列)”的习惯，那么很容易把这种写法带到非主键、允许空值的字段上，导致统计错误。

13.3 对阅读者认知成本更高

别人看到 count(id) 时，需要额外确认：

id 是否允许为 NULL
是否有业务特殊含义
这里是在统计总数，还是在统计有效主键数

而 count(*) 没有这个歧义。

十四、`count(*)`、`count(1)`、`count(列名)` 在执行计划中的常见误区

14.1 不要只看 Extra 中是否 Using Index

有些人看到 Using index 就认为一定更快。实际上还要看：

访问的索引页数量
过滤条件是否高效
是否发生范围扫描
是否有大量随机 I/O
是否需要额外排序或临时表

count 查询的瓶颈本质上是“需要扫描多少有效数据页”，而不是某个关键字是否出现在执行计划中。

14.2 不要把微基准测试当生产结论

例如在一个只有几千行数据的小表上做测试：

COUNT(*)
COUNT(1)
COUNT(id)

三条 SQL 的耗时可能看不出差别，甚至 count(1) 偶尔还快一点。但这并不能证明它在百万、千万级数据表、高并发、冷热数据混合、复杂过滤条件下仍然最优。

生产性能分析必须结合：

实际表结构
数据规模
索引设计
查询条件
事务隔离级别
慢日志
执行计划
压测结果

不能只凭一句“我测过”。

十五、在业务开发中该怎么选

15.1 统计总记录数：优先使用 `count(*)`

例如：

SELECT COUNT(*) FROM orders WHERE status = 'PAID';

这是最标准、最推荐的写法。语义明确，团队容易统一，阅读成本最低。

15.2 明确要统计某字段非空数量：使用 `count(列名)`

例如：

SELECT COUNT(delivery_time) FROM orders WHERE status = 'SHIPPED';

这表示统计已发货订单中，填写了发货时间的记录数。这里 count(列名) 的语义非常准确。

15.3 不建议为了“优化”盲目使用 `count(1)`

count(1) 不是错，但也通常不是最优表达。它适合作为一种等价写法，而不适合作为“性能优化手段”被机械推广。

如果团队要定统一规范，更推荐：

总数统计统一用 count(*)
非空字段统计用 count(列名)

这样规则最清晰。

十六、分页查询里为什么常见 `count(*)`

分页场景一般会有两条 SQL：

SELECT COUNT(*) FROM orders WHERE user_id = 10001;

SELECT * FROM orders WHERE user_id = 10001 ORDER BY created_at DESC LIMIT 0, 20;

第一条用于统计总记录数，第二条用于取当前页数据。这里总数统计必须使用能准确反映“记录总数”的写法，因此通常应使用 count(*)。

如果误写成：

SELECT COUNT(pay_time) FROM orders WHERE user_id = 10001;

那么只会统计 pay_time 非空的订单数，这通常不等于分页总数，会直接导致：

前端分页器总页数错误
“共 X 条”显示错误
翻页异常
末页数据数量不匹配

这是一个在业务代码里非常常见的低级错误。

十七、报表统计里什么时候必须用 `count(列名)`

虽然很多文章一味强调“统一用 count(*)”，但这也不完整。因为报表类需求中，count(列名) 常常是正确且必要的。

例如：

SELECT
    DATE(created_at) AS stat_date,
    COUNT(*) AS total_orders,
    COUNT(pay_time) AS paid_orders,
    COUNT(refund_time) AS refunded_orders
FROM orders
GROUP BY DATE(created_at);

这类统计表达的是：

每天创建的订单总数
其中已支付订单数
其中已退款订单数

如果 pay_time 和 refund_time 的业务语义就是“发生时才有值”，那么 count(列名) 正是最自然的统计方式。

因此，不能简单地说“永远不要用 count(列名)”。正确说法应该是：

当你要统计总行数时，用 count(*)；当你要统计某字段非空值的数量时，用 count(列名)。

十八、再谈一次 `LEFT JOIN`：为什么很多统计 SQL 看起来对，实际上错了

举一个典型业务场景：统计每个用户的订单数。

表结构示例：

DROP TABLE IF EXISTS customer;
DROP TABLE IF EXISTS orders;

CREATE TABLE customer (
    id BIGINT NOT NULL AUTO_INCREMENT COMMENT '用户ID',
    customer_name VARCHAR(64) NOT NULL COMMENT '用户名称',
    PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

CREATE TABLE orders (
    id BIGINT NOT NULL AUTO_INCREMENT COMMENT '订单ID',
    customer_id BIGINT NOT NULL COMMENT '用户ID',
    order_no VARCHAR(64) NOT NULL COMMENT '订单号',
    amount DECIMAL(12, 2) NOT NULL DEFAULT 0.00 COMMENT '订单金额',
    created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
    PRIMARY KEY (id),
    UNIQUE KEY uk_order_no (order_no),
    KEY idx_customer_id (customer_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单表';

错误写法：

SELECT
    c.id,
    c.customer_name,
    COUNT(*) AS order_count
FROM customer c
LEFT JOIN orders o ON c.id = o.customer_id
GROUP BY c.id, c.customer_name;

如果某个用户没有订单，LEFT JOIN 仍然保留该用户一行，因此 count(*) 至少是 1。这显然不符合“订单数”的业务定义。

正确写法：

SELECT
    c.id,
    c.customer_name,
    COUNT(o.id) AS order_count
FROM customer c
LEFT JOIN orders o ON c.id = o.customer_id
GROUP BY c.id, c.customer_name;

这个区别不是“写法偏好”，而是结果正确性问题。在很多生产系统里，报表数据不准、统计页对不上、看板异常，根源都来自这里。

十九、面试中常见说法，哪些对，哪些不对

19.1 “`count(1)` 比 `count(*)` 快”

这个说法不适合作为通用结论。在现代 MySQL/InnoDB 中，通常没有本质差别，优化器会做等价处理。

19.2 “`count(*)` 会解析所有列，所以慢”

这个说法是错误的。 count(*) 统计的是行，不是逐列取值再判断。

19.3 “`count(列名)` 会忽略 `NULL`”

这个说法是正确的。

19.4 “`count(主键)` 和 `count(*)` 永远一样”

从语义上不能说“永远一样”。如果主键定义为 NOT NULL，在结果上通常一致；但表达意图不同，且工程规范上仍推荐总数使用 count(*)。

19.5 “MySQL 的 `count(*)` 总是很快”

这个说法不完整。必须区分 MyISAM 和 InnoDB。在现代生产环境中，通常要按 InnoDB 的行为理解。

二十、从源码与实现思路角度理解为什么没有必要迷信 `count(1)`

虽然不展开具体源码细节，但从数据库执行器和优化器的一般实现思路来看，可以这样理解：

count(*) 被识别为总行数聚合
count(1) 被识别为对常量表达式做非空计数
因为常量 1 永不为 NULL，优化器通常会将其转化为等价的行计数逻辑
真正的成本不在“判断星号还是数字 1”，而在“如何读取满足条件的数据并完成可见性判断”

换句话说，数据库执行代价主要来自：

扫描多少页
访问哪条索引路径
是否要回表
是否有条件过滤
是否涉及事务可见性
是否存在 join、group by、having、distinct 等额外操作

把性能优化重点放在 * 和 1 上，本身就是方向偏了。

二十一、工程实践中的推荐规范

如果要在团队里制定统一 SQL 规范，可以采用下面这套规则。

21.1 规则一：统计总数统一使用 `count(*)`

原因：

语义最清晰
最符合 SQL 标准直觉
可读性最好
便于代码审查
避免误把“统计行数”和“统计字段非空数量”混在一起

21.2 规则二：统计字段有效值数量时使用 `count(列名)`

例如：

统计已填写邮箱人数
统计已支付订单数
统计已生成回执记录数

这时 count(列名) 是有业务意义的，不是替代总数统计的写法。

21.3 规则三：`LEFT JOIN` 统计右表数量时，使用 `count(右表非空主键)`

例如：

COUNT(o.id)
COUNT(e.id)
COUNT(r.id)

不要直接写 count(*)，否则很容易把“未匹配但被保留的左表行”也计入。

21.4 规则四：不要为了想象中的优化，把 `count(*)` 机械替换为 `count(1)`

这种替换通常没有收益，反而会降低代码统一性。

21.5 规则五：性能优化优先关注索引和执行计划

真正值得分析的是：

过滤条件是否命中索引
是否有覆盖索引机会
是否扫描了不必要的数据范围
是否能用预聚合、缓存、异步统计替代实时全表扫描
超大表是否需要分区、分库分表或近实时统计表

二十二、超大表统计总数时，真正该考虑什么

当表达到千万级、亿级以后，count(*) 慢并不是因为你写了 *，而是因为“精确统计总行数”本身就昂贵。

这时真正可行的方案通常包括：

22.1 使用缓存计数

例如在 Redis 中维护某些业务维度的计数器，但要处理好一致性问题。

22.2 使用汇总表或中间统计表

通过异步任务、消息队列、定时作业把明细数据汇总到统计表中，查询时直接读取聚合结果。

22.3 接受近似值

对某些列表页、搜索页，如果业务允许，可以使用估算值而不是每次精确 count(*)。

22.4 限制深分页

很多系统总数统计慢，本质上不是 count 本身，而是分页模型设计不合理。

22.5 合理设计索引和查询条件

让数据库尽可能扫描更小的数据范围，而不是全表或大范围扫描。

这些才是大规模场景下的正确优化方向。

二十三、一个最终可直接记忆的判断表

下面给出一个可以直接落地到开发规范里的总结。

写法	统计对象	是否忽略 `NULL`	常见用途	是否推荐作为“总数统计”默认写法
`count(*)`	结果集总行数	不忽略	统计总记录数、分页总数、分组总量	是
`count(1)`	常量表达式非空数量	不忽略	与 `count(*)` 结果通常一致	一般不作为默认规范
`count(列名)`	指定列非空值数量	忽略 `NULL`	统计字段有效值数量、覆盖率、业务状态数量	否

二十四、最容易记错的三个结论

24.1 结论一

count(*) 和 count(1) 在结果语义上通常一致，都是统计行数。

24.2 结论二

count(列名) 统计的是该列不为 NULL 的数量，不等于总行数。

24.3 结论三

在 LEFT JOIN 场景下，count(*) 和 count(右表列) 可能差别巨大，必须根据业务语义选择。

二十五、最终结论

count(1)、count(*) 与 count(列名) 的区别，本质上不是“谁语法更高级”，也不是“谁一定更快”，而是统计语义不同。

可以把它们压缩成三句话：

count(*)：统计结果集总行数，推荐用于总数统计
count(1)：通常与 count(*) 等价，在现代数据库中性能通常无本质差异
count(列名)：统计该列非 NULL 的数量，适合统计有效值，不适合作为总数统计的默认写法

如果再往工程实践层面收敛成一条最有价值的建议，那就是：

当你要表达“总共有多少行”时，写 count(*)；当你要表达“这个字段有多少个有效值”时，写 count(列名)；不要把两者混为一谈，更不要把 count(1) 当作性能优化口诀。

只有把语义、执行逻辑、NULL 行为、连接场景和存储引擎差异都理解清楚，才能真正把这个看似基础的问题用对、讲清、写准。

正文到此结束

所属分类：Mysql

本文链接： https://refblogs.com/article/1209
版权声明： 本文由老牛原创发布，转载或复制请以超链接形式转载,并注明出处搬砖的码农。

count(1)、count(*) 与 count(列名) 的区别详解

一、为什么这个问题总被反复讨论

二、先从 SQL 标准语义说起

2.1 聚合函数 COUNT 的基本定义

2.2 为什么 count(1) 和 count(*) 常被认为一样

2.3 为什么 count(列名) 不一样

三、通过一个完整示例理解三者区别

3.1 建表 SQL

3.2 执行不同 SQL

四、从执行逻辑上看三者到底做了什么

4.1 count(*) 的逻辑含义

4.2 count(1) 的逻辑含义

4.3 count(列名) 的逻辑含义

五、最容易出错的地方：NULL 对统计结果的影响

5.1 count(*) 不受 NULL 影响

5.2 count(列名) 会受 NULL 影响