直接查information_schema.tables最快但不准：table_rows是innodb基于采样估算的值，误差可达±40%，不反映未提交事务或刚插入未刷盘数据，仅适用于趋势监控等非精确场景；myisam下虽精确但已不推荐新用。
直接查INFORMATION_SCHEMA.TABLES最快但不准
当你要的只是“大概有多少行”，比如运营后台看个趋势、监控告警阈值判断，SELECT table_rows FROM INFORMATION_SCHEMA.TABLES WHERE table_schema = 'db_name' AND table_name = 'table_name' 是唯一能毫秒返回的方案。InnoDB 会基于采样统计维护这个估算值，不扫描数据，也不加锁。
但它误差可能达 ±40%，且不反映未提交事务、刚插入但未刷盘的数据。别在账务、审计、强一致分页总数等场景用它——table_rows 是估算，不是事实。
- 执行
ANALYZE TABLE table_name可手动更新采样，但别高频跑，会阻塞写入 - MyISAM 表的
table_rows是精确值，但 MyISAM 基本不该再用于新业务 - 如果表刚经历大批量 DELETE，
table_rows可能严重高估，因为 InnoDB 不实时回收空间统计
EXPLAIN 的 rows 字段不是真行数，别当 COUNT 用
有人发现 EXPLAIN SELECT * FROM t 返回的 rows 值接近总行数，就拿它当 COUNT 替代——这是危险误解。rows 是优化器对本次查询“预估要检查的行数”，受 WHERE 条件、索引选择、统计信息新鲜度影响极大。没 WHERE 的全表扫描时它才偶尔接近真实值，但依然只是估算，且不保证一致性。
更关键的是：EXPLAIN 不加锁、不校验 MVCC 版本，它看到的可能是被其他事务删除但尚未清理的“幻影行”，也可能漏掉刚插入但未提交的行。
- 不要在任何生产逻辑里依赖
EXPLAIN ... rows作为计数依据 - 它适合调优时快速判断扫描范围，不适合替代
COUNT - 对比
SELECT COUNT(*)和EXPLAIN的rows，你会发现二者在并发写入频繁的表上经常差几万条
带 WHERE 条件的 COUNT 必须走覆盖索引，否则就是全表扫
真正拖垮性能的从来不是 COUNT(*) 本身，而是 WHERE status = 'paid' 这类条件没索引。MySQL 要么全表扫描，要么回表判断每一行是否满足条件——后者比前者还慢，因为要随机 IO 读聚簇索引。
优化核心只有一条：让 COUNT(*) 查询能仅靠二级索引完成，即“索引覆盖”。最稳妥是建联合索引，把 WHERE 字段放最左，末尾补一个非空字段（如主键 id）：
ALTER TABLE orders ADD INDEX idx_status_id (status, id);
验证是否生效：EXPLAIN SELECT COUNT(*) FROM orders WHERE status = 'paid'，确认 key 列显示 idx_status_id，且 Extra 含 Using index。
- 单列
INDEX(status)在某些版本可能仍触发回表，尤其当status区分度低（如 90% 都是'pending'）时 - 如果 WHERE 条件含多个字段，联合索引顺序必须严格匹配最左前缀，
(a,b)无法加速WHERE b = ? - 索引本身有维护成本，高频写入表需权衡；但相比每次 COUNT 扫千万行，这点开销几乎可忽略
精确计数 + 高频访问 = 必须用缓存或计数表
当业务既要求绝对准确（比如支付成功订单数），又要求毫秒响应（比如首页实时展示），靠数据库原生 COUNT 已无解。这时必须把计数逻辑移出 MySQL 主表。
两种主流落地方式：
- Redis 计数器：
INCRBY order_count_paid 1在订单状态变为'paid'时执行，事务中先更新 DB 再更新 Redis（注意失败回滚）。缺点是网络分区时可能丢失，需配合补偿任务 - 独立计数表：
CREATE TABLE order_count (status VARCHAR(20) PRIMARY KEY, cnt BIGINT NOT NULL DEFAULT 0)，所有状态变更通过INSERT ... ON DUPLICATE KEY UPDATE cnt = cnt + 1维护。强一致，但写放大，适合变更频率可控的场景
别试图用触发器自动维护计数表——InnoDB 触发器在高并发下极易成为瓶颈，且难以调试。
