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 字段) 更狠：需去重，触发临时表或排序，内存/磁盘开销陡增。
CRMEB Min开源商城
下载
CRMEB Min是CRMEB品牌全新推出的一款轻量级、高性能、前后端分离的开源电商系统，完善的后台权限管理、会员管理、订单管理、产品管理、客服系统、CMS管理、多端管理、页面DIY、数据统计、系统配置、组合数据管理、日志管理、数据库管理，一键开通短信、产品采集、物流查询等接口，系统采用TP6+Mysql+Uniapp+iView+Redis+workerman+form-builder等最流行热
-
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 的一致性模型决定了它不会给你一个“全局快照行数”，你拿到的永远是“当前事务视角下的可见行数”。
