count()快因MyISAM缓存行数，InnoDB需逐行判断可见性；加WHERE均需全表扫描；count()、count(1)、count(主键)语义等价且性能无显著差异；count(字段)需判NULL，count(distinct 字段)更慢；高频场景应缓存、用估算或业务妥协。

count(*) 为什么快，但加 WHERE 就变慢？

因为 count(*) 的性能高度依赖存储引擎：MyISAM 引擎把总行数固化在磁盘（PARTITIONS 表里），不带 WHERE 时直接返回；而 InnoDB 没法这么干——它支持事务和 MVCC，同一时刻不同事务看到的“行数”可能不同，必须逐行判断是否可见。

• MyISAM：SELECT COUNT(*) FROM person; → 瞬间返回（哪怕千万行）
• InnoDB：SELECT COUNT(*) FROM user; → 全表扫描聚簇索引，一行行读、一行行判可见性
• 只要加了 WHERE 条件（哪怕 WHERE 1），MyISAM 也得全表扫，InnoDB 更是逃不掉

count(1)、count(*)、count(主键) 到底有区别吗？

语义上完全等价：三者都统计「满足条件的非 NULL 行数」。由于 1 和 * 永远不为 NULL，主键 在 InnoDB 中也必然非 NULL，所以最终结果一致。

• 优化器通常会把 count(*) 和 count(1) 视为同一类操作，甚至内部都转成 count(1)
• count(id)（id 是主键）在有二级索引时，可能走最小的二级索引树（I/O 更少），但实际差异微乎其微
• 别迷信“count(1) 比 count(*) 快”——MySQL 8.0+ 下二者执行计划几乎一样

count(字段) 和 count(distinct 字段) 是真·慢操作

count(字段) 不仅要判断行是否满足条件，还要读取该字段值并检查是否为 NULL；count(distinct 字段) 更狠：需去重，触发临时表或排序，内存/磁盘开销陡增。

• SELECT COUNT(email) FROM user; → 要读每行的 email 字段，跳过 NULL
• SELECT COUNT(DISTINCT email) FROM user; → 可能用到 Using temporary; Using filesort，百万级数据秒变秒级延迟
• 如果业务上确定某列非空（如主键、自增 ID），用 count(*) 更安全，也更易被优化器识别为“可走索引统计”

高频 count 场景怎么避免拖垮查询？

分页总数、后台报表、实时监控——这些地方反复查 COUNT(*) 是大忌。InnoDB 表越大，越容易卡住整个连接池。

• 用缓存：对变动不频繁的表，把 COUNT(*) 结果存在 Redis，定时或通过 binlog 更新
• 用近似值：对“大概多少条”够用的场景，查 information_schema.PARTITIONS（InnoDB 表的 TABLE_ROWS 是估算值，误差可能达 40%）
• 业务妥协：首页只显示“已加载 20 条”，不显示“共 1278923 条”；搜索页用“显示前 5000 条”代替精确总数
• 千万别用 count(字段) 替代 count(*) “图省事”——比如写 count(user_name) 以为等于总人数，结果 NULL 用户被漏掉

真正难的不是写对 COUNT，而是想清楚：这个数字是不是此刻必须精确？有没有替代路径？InnoDB 的一致性模型决定了它不会给你一个“全局快照行数”，你拿到的永远是“当前事务视角下的可见行数”。