count() 统计所有行，包括NULL值，是统计总行数的首选方法；2. count(1) 与 count() 在现代数据库中性能几乎无差异，两者均统计所有行；3. count(列名) 仅统计指定列非null值的行数，结果可能小于 count()；4. count(distinct 列名) 用于统计某列去重后的不重复值数量；5. 在复杂查询中，count 可与 group by、having 和 case when 结合实现分组统计、条件过滤和条件计数；6. 常见误区包括混淆 count() 与 count(列名) 的语义差异及忽视全表扫描性能问题；7. 优化建议包括理解数据是否含null、合理使用索引、避免where中使用函数、对超大表考虑近似值或物化视图。因此，正确选择 count 的用法并结合索引与查询结构优化，才能高效准确地完成统计任务。
在sql里，要统计表中记录总数，最直接、最常用的函数就是
COUNT()
。它能帮你快速得到一个数据集里到底有多少行，无论是整个表，还是特定条件下的记录，它都是我们做数据分析和报表时离不开的基础工具。
解决方案
要统计表中记录总数，最基础也是最常见的方式就是使用
COUNT(*)
。这个星号代表着“所有行”，它会统计指定查询结果集中的所有行，包括那些包含NULL值的行。
假设我们有一个名为
employees
的表，想要知道里面总共有多少名员工：
SELECT COUNT(*) FROM employees;
如果你想统计某个特定列非NULL值的数量，可以使用
COUNT(列名)
。这在某些场景下非常有用，比如你想知道有多少员工填写了他们的邮箱地址（假设邮箱列可能存在NULL值）：
SELECT COUNT(email) FROM employees;
还有一种情况，如果你想统计某个列的不重复值的数量，就需要用到
COUNT(DISTINCT 列名)
。比如，想知道公司有多少个不同的部门：
SELECT COUNT(DISTINCT department_id) FROM employees;
这些都是
COUNT
函数最直接、最基础的用法，它们各自服务于不同的统计目的。选择哪种，完全取决于你到底想数什么。
COUNT(*), COUNT(1) 和 COUNT(列名) 有什么区别？哪个性能更好？
这确实是个老生常谈的问题，尤其是在数据库优化讨论中。我个人觉得，理解它们之间的细微差别比纠结于那一点点理论上的性能差异更重要，因为在大多数现代数据库系统里，优化器已经非常智能了。
从功能上讲：
-
COUNT(*)
：这是ANSI SQL标准规定的用法，它会统计所有行，不关心行里的具体内容，包括NULL值。你可以把它理解为“数行数”。
-
COUNT(1)
：它和
COUNT(*)
的效果几乎一样，也是统计所有行。这里的
1
只是一个常量，数据库在执行时并不会真的去读取这个
1
，而是用它来表示“每一行”。它同样不关心NULL值。
-
COUNT(列名)
：这个就比较明确了，它只统计指定
列名
中非NULL值的行数。如果某一行的该列是NULL，那么这一行就不会被计入。
关于性能： 在很多早期的数据库系统或特定场景下，可能会有
COUNT(1)
比
COUNT(*)
快的说法，因为理论上
COUNT(*)
可能需要检查更多元数据。但实际上，对于现代的SQL Server、mysql、postgresql等主流数据库，它们的查询优化器已经非常成熟，
COUNT(*)
和
COUNT(1)
通常会被优化成相同的执行计划，性能上几乎没有差异。它们都倾向于选择最快的索引（通常是主键索引）来完成计数。
COUNT(列名)
的性能则可能有所不同。如果
列名
上没有索引，或者该列的数据量非常大且NULL值很多，数据库可能需要进行全表扫描来判断哪些值是非NULL的，这可能会比
COUNT(*)
或
COUNT(1)
慢。但如果
列名
上有合适的索引，并且这个索引可以覆盖查询，那性能也可能非常好。
所以，我的建议是：
- 如果你只是想统计总行数，*始终优先使用`COUNT()
**。它语义最清晰，是标准用法，并且在现代数据库中性能通常与
COUNT(1)`无异。
- 如果你需要统计某个列的非NULL值数量，就用
COUNT(列名)
。
- 如果你需要统计某个列的不重复值数量，那就用
COUNT(DISTINCT 列名)
。
不要过分纠结
COUNT(*)
和
COUNT(1)
的性能，把精力放在理解业务需求和选择正确的函数上。
COUNT 函数在复杂查询中如何应用？
COUNT
函数远不止统计总数那么简单，它在配合
GROUP BY
、
HAVING
、
WHERE
子句时，能发挥出强大的聚合分析能力。这才是它真正让人着迷的地方，能从一堆原始数据里提炼出有意义的洞察。
比如，我们想知道每个部门有多少名员工：
SELECT department_id, COUNT(*) AS employee_count FROM employees GROUP BY department_id;
这里，
GROUP BY department_id
将员工按照部门分组，然后
COUNT(*)
对每个组内的员工进行计数。这一下，每个部门的人数就一目了然了。
再复杂一点，如果我只想看员工数量超过10人的部门：
SELECT department_id, COUNT(*) AS employee_count FROM employees GROUP BY department_id HAVING COUNT(*) > 10;
HAVING
子句在这里起到了关键作用，它是在
GROUP BY
聚合之后，对聚合结果进行过滤。如果直接在
WHERE
子句里写
WHERE COUNT(*) > 10
，那肯定会报错，因为
WHERE
是在分组之前对原始行进行过滤的。
你甚至可以在
COUNT
函数内部加入
CASE WHEN
表达式，实现更精细的条件计数。比如，统计每个部门有多少名男性员工和女性员工：
SELECT department_id, COUNT(CASE WHEN gender = 'Male' THEN 1 ELSE NULL END) AS male_employees, COUNT(CASE WHEN gender = 'Female' THEN 1 ELSE NULL END) AS female_employees FROM employees GROUP BY department_id;
这里，
COUNT(CASE WHEN ... THEN 1 ELSE NULL END)
的巧妙之处在于，当条件不满足时，
CASE
表达式返回
NULL
，而
COUNT()
函数会忽略
NULL
值，从而实现了条件计数。这比分开写两个子查询或者多个
JOIN
要简洁高效得多。
这种组合使用的方式，让
COUNT
函数变得非常灵活，能够满足各种复杂的统计需求，是数据分析师和开发者日常工作中不可或缺的技能。
使用 COUNT 函数时常见的误区和优化建议
即便
COUNT
函数看起来很简单，但在实际使用中，尤其是在处理大数据量或复杂业务逻辑时，还是有一些常见的误区和可以优化的点。
一个很常见的误区就是对
COUNT(列名)
的理解不透彻。很多人会想当然地认为
COUNT(列名)
和
COUNT(*)
会得到相同的结果，但前面也提到了，
COUNT(列名)
会忽略NULL值。如果你不清楚这一点，在统计某些可能存在NULL值的字段时，结果可能会让你感到困惑，甚至导致错误的业务决策。比如，统计用户注册数量，如果用
COUNT(phone_number)
，而有些用户注册时没填手机号，那统计结果就会偏少。
另一个误区是过度依赖全表扫描。当表非常大时，
COUNT(*)
或者没有索引的
COUNT(列名)
可能会导致全表扫描，这会非常耗时。虽然数据库优化器会尽力选择最优路径，但如果表没有主键或者合适的索引，它也无能为力。
优化建议：
- 理解数据特性： 在使用
COUNT
前，先搞清楚你所统计的列是否允许NULL值，以及业务上对NULL值的定义是什么。这决定了你该用
COUNT(*)
、
COUNT(列名)
还是
COUNT(DISTINCT 列名)
。
- 善用索引： 对于
COUNT(*)
，数据库通常会选择一个最小的索引（比如主键索引）来快速计数。确保你的表有主键。对于
COUNT(列名)
，如果该列经常被用来计数或过滤，考虑为其创建索引。尤其是
COUNT(DISTINCT 列名)
，没有索引的
DISTINCT
操作在大量数据下会非常慢。
- 避免在
WHERE
子句中使用函数或复杂表达式：
这会阻止索引的使用，导致全表扫描。如果可能，尽量将条件简化或预处理。 - 分批处理或使用近似值（针对超大数据量）： 对于拥有亿万级记录的超大表，即使是
COUNT(*)
也可能耗时数秒甚至数十秒。在某些场景下，如果你只需要一个近似值，可以考虑：
- 数据库统计信息： 很多数据库系统会维护表的统计信息，比如表的总行数。虽然这些信息可能不是实时精确的，但对于快速获取一个大概的数字非常有用。例如，MySQL的
INFORMATION_SCHEMA.TABLES
表中的
TABLE_ROWS
字段，虽然有延迟，但能快速提供近似值。
- 抽样： 对数据进行抽样，然后估算总数。但这通常需要更复杂的SQL或编程逻辑。
- 数据库统计信息： 很多数据库系统会维护表的统计信息，比如表的总行数。虽然这些信息可能不是实时精确的，但对于快速获取一个大概的数字非常有用。例如，MySQL的
- 合理利用物化视图或汇总表： 如果某些
COUNT
操作是高频的，并且数据变化不是特别频繁，可以考虑创建物化视图（Materialized View）或定时更新的汇总表，将
COUNT
的结果预先计算并存储起来，查询时直接从汇总表读取，大大提高查询速度。
总的来说，
COUNT
函数看似简单，但其背后的逻辑和优化空间不容小觑。深入理解它的行为，并结合实际场景进行优化，才能真正发挥它的威力。
