phpMyAdmin执行COUNT(*)界面崩溃并非因COUNT慢，而是触发全表扫描+全结果渲染链路：先SHOW TABLE STATUS获取元数据，再执行COUNT但用mysql_fetch_all遍历单行，最后套入150KB HTML模板致响应超2MB，浏览器解析内存峰值破1GB。
phpMyAdmin 执行 COUNT(*) 时界面崩溃，根本不是因为 COUNT 本身慢，而是它触发了 phpMyAdmin 的全表扫描 + 全结果渲染链路——哪怕只返回一个数字，它仍会尝试把整张表的元数据、索引统计、甚至表结构变更历史都拉一遍，再拼成巨量 HTML 发给浏览器。
为什么 COUNT(*) 在 phpMyAdmin 里比命令行还卡
MySQL 命令行执行 COUNT(*) 只返回一行数字，但 phpMyAdmin 会额外做三件事：
- 先发
SHOW TABLE STATUS LIKE 'table_name'拿表大小和引擎信息（对千万级表，这语句本身可能锁表或扫元数据缓存） - 再执行你的
SELECT COUNT(*) FROM huge_table，但 PHP 层用的是mysql_fetch_all()类函数，哪怕结果只有一行，也会走完整结果集遍历流程 - 最后把这一行数字套进带分页栏、导出按钮、字段类型提示的 HTML 模板里——模板体积固定约 150KB，叠加服务器响应头、JS 初始化脚本，总输出常超 2MB
浏览器收到这个“单行结果+2MB包装”的响应后，要解析 DOM、执行 JS、渲染表格外壳，内存峰值轻松破 1GB，低端设备直接无响应或崩溃。
COUNT(*) 被强制转成 SELECT * 的隐藏行为
某些 phpMyAdmin 版本（尤其是 5.1+）在检测到未指定 LIMIT 且表行数预估 > 10 万时，会悄悄把原始语句重写为：
立即学习“PHP免费学习笔记（深入）”；
SELECT SQL_CALC_FOUND_ROWS * FROM huge_table LIMIT 1
然后靠 SELECT FOUND_ROWS() 模拟 COUNT——这反而更糟，因为：
-
SQL_CALC_FOUND_ROWS在 InnoDB 上已弃用，且强制走主键全扫描 - 即使加了
LIMIT 1，MySQL 仍需初始化整个结果集结构，PHP 层仍会分配数组容器 - 该行为不受
$cfg['MaxRows']控制，配置再小也拦不住
真正安全的替代方案：绕过 phpMyAdmin 渲染层
查大表行数不该依赖界面工具，而应直连 MySQL 并控制输出粒度：
- 用命令行：
mysql -u root -p -e "SELECT COUNT(*) FROM database.table;"—— 输出纯文本，无 HTML 开销 - 查近似值（快百倍）：
SELECT table_rows FROM information_schema.tables WHERE table_schema='database' AND table_name='table';—— 读的是统计缓存，不扫数据 - 如果必须用 phpMyAdmin，先在 SQL 窗口执行
SET SESSION sql_calc_found_rows = OFF;，再跑COUNT(*)，可禁用重写逻辑 - 临时禁用元数据加载：编辑
config.inc.php加上$cfg['SkipLockedTables'] = true;和$cfg['ShowFunctionFields'] = false;，减少附加查询
记住：phpMyAdmin 的 UI 是为管理、调试、小批量操作设计的，不是为吞吐优化。当看到“正在加载…”超过 5 秒，就该切到终端了——那不是失败信号，是系统在提醒你，该换工具链了。
