phpMyAdmin 表列表中显示的行数来自 SHOW TABLE STATUS 的 Rows 字段，是 InnoDB 的采样估算值，误差可达 ±40%，不扫描数据、仅读内存快照，故快但不准；真正精确的行数必须执行 SELECT COUNT(*) FROM table_name。
phpMyAdmin 显示的行数来自 SHOW TABLE STATUS 估算值
phpmyadmin 左侧表列表里显示的“2892865 行”，不是执行 count(*) 得到的，而是调用 show table status 后取 rows 字段——这个值对 innodb 表来说是采样估算值，误差可能达 ±40%。它不扫描数据，只读内存里的统计快照，所以快但不准。
常见现象包括：删掉 10 万行后仍显示旧数字；刚插入一批数据却没立刻更新；多线程写入时数值来回跳变。
- 该估算值不受事务隔离级别影响，也不等待 MVCC 一致性视图
- 即使表完全空了，
Rows也可能显示几百甚至几千（InnoDB 的采样偏差） -
$cfg['MaxExactCount'] = 10000000;只影响 phpMyAdmin 内部是否自动改用COUNT(*)查询，不改变SHOW TABLE STATUS本身的逻辑
COUNT(*) 和 COUNT(列名) 在同一查询里结果不同是正常行为
如果你在 phpMyAdmin 的 SQL 窗口中手动执行 COUNT(*) 和 COUNT(id) 得到不同结果，这不是 phpMyAdmin 的 bug，而是 SQL 标准强制语义：
-
COUNT(*)统计所有行，不管字段是否为NULL -
COUNT(列名)跳过该列为NULL的每一行，只数非空值 - 差值就是该列中
NULL的数量 —— 即使是主键字段，只要没加NOT NULL约束，就可能出现NULL
例如：COUNT(*) 返回 100，COUNT(user_id) 返回 97 → 说明有 3 行 user_id IS NULL。这个差异在 LEFT JOIN 后更明显，右表字段匹配失败即为 NULL，COUNT(右表.id) 实际统计的是“成功关联的行数”，不是左表原始行数。
phpMyAdmin 分页跳转末页出错，本质是依赖了错误的行数基准
当你点击“最后一页”，phpMyAdmin 默认用 SHOW TABLE STATUS 的 Rows 值算总页数，再反推 LIMIT 偏移量。但若估算值比实际多（比如显示 2892865，实际只有 2891055），最后一组 LIMIT 就会越界，返回空结果或报错。
立即学习“PHP免费学习笔记（深入）”；
- 修复方式不是“让估算变准”，而是让 phpMyAdmin 改用精确计数：在
config.inc.php中加$cfg['MaxExactCount'] = 10000000; - 该配置仅对行数 ≤ 1000 万的表启用
COUNT(*)查询，避免大表卡死界面 - 若表超限，它仍回落到估算值 —— 这是权衡，不是缺陷
真正需要精确行数时，别信任何元数据，直接跑 COUNT(*)
无论是 phpMyAdmin、Navicat 还是 INFORMATION_SCHEMA.TABLES.TABLE_ROWS，只要底层是 InnoDB，它们展示的“行数”都只是快照估算。唯一可靠的方式永远是：
SELECT COUNT(*) FROM `your_table`;
注意三点：
- 执行时受当前事务隔离级别影响：可重复读下看到的是事务开始时的一致性快照，不是最新物理状态
- 无索引的大表执行慢，但结果一定准；别用
COUNT(1)或COUNT(pk)试图“优化”，现代 MySQL 对三者生成的执行计划基本一致 - 如果连
COUNT(*)都慢到不可接受，说明你真该考虑归档旧数据、加覆盖索引，或者用近似计数方案（如 HyperLogLog），而不是纠结元数据准不准
最常被忽略的一点：估算值和精确值之间的 gap 不会报错，也不会警告，它就安静地藏在分页链接、导出总数、后台监控图表里，直到某天导出缺了几百条数据，才被人发现。
