count(*)是统计行数的唯一可靠写法，它不依赖列值是否为null，严格遵循sql92标准，所有主流mysql版本均支持。
count(*) 是统计行数的唯一可靠写法
想查表里一共有多少条记录？直接用 COUNT(*)，别犹豫。它不依赖任何列，也不管字段是不是 NULL，就是数“行”本身——这是 SQL92 标准定义的行为，所有主流 MySQL 版本（包括 8.0+）都严格遵循。
-
COUNT(列名)只统计该列非 NULL 的行，如果字段本身允许 NULL（比如customer_id有缺失），结果就少于真实行数 -
COUNT(1)虽然在某些旧文档里被说成“更快”，但 InnoDB 下和COUNT(*)实际执行路径几乎一致；MyISAM 表虽有内部计数器，但已不推荐用于新项目 - 别信“
COUNT(主键)更快”的说法——除非你确定主键列绝对非空且无索引失效风险，否则纯属过早优化，还可能因隐式类型转换翻车
分组统计时必须配 GROUP BY，否则语法报错
你要按 SIC Code 分类统计数量，却写了 SELECT SIC_Codes, COUNT(*) FROM company_list ...？MySQL 会直接报错：「Expression #1 of SELECT list is not in GROUP BY clause」。这不是 bug，是 SQL 标准强制要求：只要 SELECT 里有聚合函数（如 COUNT、SUM），所有非聚合字段都必须出现在 GROUP BY 中。
- 正确写法：
SELECT company_list.SIC_Codes, sic_codes.SIC_desc, COUNT(*) AS sicCount FROM company_list LEFT JOIN sic_codes ON company_list.SIC_Codes = sic_codes.SIC_code GROUP BY company_list.SIC_Codes, sic_codes.SIC_desc - 别用
DISTINCT + COUNT(*)混搭——那不是分组，只是去重后硬套总数，结果完全不对 - 如果只想看某几个 SIC Code 的数量，WHERE 条件要放在 GROUP BY 之前，而不是之后（HAVING 是过滤分组结果，不是筛选原始行）
遇到 NULL 值，sum() 返回 NULL 而 count() 返回 0
统计金额总和时，如果整张表的 amount 全是 NULL，SUM(amount) 返回的是 NULL，不是 0。下游代码若没判空，极易触发 NPE 或前端展示异常；而 COUNT(customer_id) 在同场景下返回 0，行为稳定。
- 安全写法：
COALESCE(SUM(amount), 0)或IFNULL(SUM(amount), 0)，两者等效，选顺手的 -
COUNT(DISTINCT col)会自动跳过 NULL 值，但COUNT(DISTINCT col1, col2)要求两列**同时非 NULL** 才计入——哪怕col1有值、col2全是 NULL，结果也是 0 - 别用
ISNULL(COUNT(*))——COUNT(*)永远不会是 NULL，这个判断毫无意义
WHERE 和 HAVING 别混用，顺序错了结果就错
很多人把条件塞进 HAVING 以为“反正都是过滤”，但语义完全不同：WHERE 过滤的是原始数据行，HAVING 过滤的是分组后的聚合结果。比如想查“订单数超过 100 的客户”，必须先 GROUP BY customer_id，再用 HAVING COUNT(*) > 100；如果写成 WHERE COUNT(*) > 100，MySQL 直接拒绝执行。
- 执行顺序固定：
WHERE → GROUP BY → HAVING → ORDER BY → LIMIT，少一个环节或颠倒顺序，要么报错，要么逻辑错误 -
HAVING后面只能跟分组字段或聚合表达式，不能写原始表里的未分组字段（如HAVING order_date > '2025-01-01'是非法的） - 性能上，
WHERE越早筛掉无效行，GROUP BY处理的数据量就越小——所以能放 WHERE 的条件，绝不拖到 HAVING
最常被忽略的一点：COUNT(*) 在大表上仍是全表扫描，没有索引能跳过。如果只是想确认“有没有数据”，用 EXISTS (SELECT 1 FROM t WHERE ...) 更轻量；真要高频查总数，得考虑加汇总表或缓存层——别指望换一个括号就能解决性能问题。
