myisam的count(*)秒出，因其直接读取磁盘元数据中预存的精确行数；innodb则必须遍历最小索引树逐行判断mvcc可见性并累加，无法预存全局值，故准确但较慢。
MyISAM 表直接读元数据，COUNT(*) 秒出；InnoDB 表必须扫描索引，COUNT(*) 是唯一准确方式，但不能图快硬上——得看场景、看引擎、看能不能接受误差。
MyISAM 表：COUNT(*) 就是查缓存，别折腾
MyISAM 在表头里存了精确行数，COUNT(*) 不走磁盘、不扫索引，纯内存读取。哪怕几亿行，也毫秒级返回。
- 无需加
WHERE条件也能飞快执行 -
COUNT(1)和COUNT(*)完全等价，没差别 - 注意：MyISAM 不支持事务，如果业务依赖 ACID，基本不该用它
InnoDB 表：没有“快而准”的捷径，只有“快但不准”或“准但慢”
InnoDB 的 COUNT(*) 必须遍历最小索引树（通常是二级索引），逐页读叶子节点计数。这不是优化不到位，而是 MVCC 下每个事务看到的“可见行数”不同，没法预存一个全局值。
- 估算行数可查
information_schema.tables.table_rows，但误差常达 20%～50%，刚大批 INSERT 后尤其不准 -
SHOW TABLE STATUS LIKE 't'返回的Rows列和上面一样，只是多带了Data_length等字段，适合看容量趋势 - 真要精确值，只能跑
COUNT(*)，且建议：避开高峰、优先查从库、别在长事务里嵌套它
别被 COUNT(1) 或 COUNT(id) 带偏，它们对 InnoDB 没提速作用
MySQL 优化器对 COUNT(*) 和 COUNT(1) 一视同仁，都会选最小索引；而 COUNT(id)（主键）反而可能被迫走聚簇索引，更重。
COUNT(*) ≈ COUNT(1) > COUNT(主键) > COUNT(普通列) > COUNT(无索引列)-
COUNT(普通列)还要额外判断是否为NULL，除非你明确要排除空值，否则纯属自找麻烦 - 别信“
COUNT(1)比COUNT(*)快”的老话——那是 MySQL 4.x 时代的残余认知，现代版本已无实质差异
日常巡检和容量评估，用 information_schema 查就行，但得加过滤
想一眼看清库内各表大小和估算行数，information_schema.tables 是唯一实用入口。但不加约束会扫全实例元数据，慢且没必要。
- 必须写
WHERE table_schema = 'your_db'，否则可能卡住元数据锁 - 对空表，低版本 MySQL（如 5.6）中
table_rows可能为NULL，记得包一层IFNULL(table_rows, 0) - 搭配
data_length + index_length看存储膨胀比看行数更有价值，比如某表table_rows没变但data_length翻倍，大概率有大量软删除或未 purge 的旧版本
真正难的不是怎么查，而是想清楚：你要这个数字干什么？做监控告警阈值？那估算值够用；核对迁移数据一致性？必须 COUNT(*)；给老板汇报“系统总数据量”？得说明是估算还是实测——没人会怪你坦白误差来源，但没人想替你背锅。
