phpEnv中查MySQL表空间不能只信information_schema.TABLES——它仅提供逻辑估算值；真实占用需看文件系统，如ibdata1、ibtmp1、binlog等均不体现在SQL结果中。
phpEnv 里查 MySQL 表空间，不能只信 information_schema.TABLES 的结果——它给的是逻辑估算值，不是磁盘上真实占了多少字节。 真实占用得看文件系统，尤其是 phpEnv 这种本地集成环境，默认 datadir 通常在 C:\phpEnv\MySQL\data（Windows）或 /usr/local/phpenv/mysql/data（macOS/Linux），而 ibdata1、ib_logfile*、binlog 等关键文件完全不露面于 SQL 查询中。
为什么 SELECT data_length + index_length 不准
这个值只反映 InnoDB/BTree 层的数据页和索引页分配量，但忽略以下事实：
-
innodb_file_per_table=OFF时，所有表数据都挤进共享表空间ibdata1，而该文件大小不会拆分到任何单表统计里 -
ibtmp1（临时表空间）、ib_logfile*（redo log）、mysql-bin.*（binlog）全都不计入information_schema，但它们加起来可能比所有.ibd文件还大 - 文件系统块对齐：一个 2KB 的记录实际可能占满 4KB 磁盘块，
du -sh看到的才是真实字节数 -
DATA_FREE字段常被误读为“剩余空间”，其实只是 .ibd 内部未填满的页，文件本身不会自动收缩
phpEnv 下快速定位大表的两种路径
先确认你的 MySQL 是否启用独立表空间：
mysql -e "SHOW VARIABLES LIKE 'innodb_file_per_table';"
若返回 ON，可安全走文件系统路径；若为 OFF，必须立刻检查 ibdata1 大小——它很可能已膨胀到数 GB，而你查出来的所有表加起来才几百 MB。
立即学习“PHP免费学习笔记（深入）”；
- SQL 路径（适合快速排序）：
执行：SELECT table_name, ROUND((data_length + index_length)/1024/1024, 2) AS size_mb FROM information_schema.tables WHERE table_schema = 'your_db' ORDER BY size_mb DESC LIMIT 10; - 文件系统路径（更真实）：
Windows：打开资源管理器，进入C:\phpEnv\MySQL\data\your_db\，按“大小”排序看最大的.ibd文件
macOS/Linux：du -sh /usr/local/phpenv/mysql/data/your_db/*.ibd 2>/dev/null | sort -hr | head -10
容易踩的坑：删错文件 or 误判瓶颈
常见错误操作和后果：
- 看到
ibdata1很大，直接删掉 → MySQL 启动失败，报错Table 'mysql.plugin' doesn't exist或直接拒绝启动 - 用
SHOW TABLE STATUS查Data_free较高就执行OPTIMIZE TABLE→ 对大表锁表时间长，且在 phpEnv 这类开发环境里往往没必要（没高压写入） - 只查
information_schema.TABLES就以为磁盘快满了 → 其实是mysql-bin.0000xx日志没清理，或者ibtmp1占了几个 GB（尤其执行过大型 GROUP BY 或临时表查询后） - 在 phpEnv 控制面板里点“重启 MySQL”后发现磁盘空间突增 → 很可能是重启触发了 redo log 切换或临时文件残留，需手动清理
ibtmp1（停服务后删）
最常被忽略的一点：phpEnv 默认开启 binlog，但很少配置 expire_logs_days。跑一周可能生成几十个 mysql-bin.000xxx 文件，总大小远超业务库本身。别只盯着表，先 du -sh 扫一遍整个 data 目录再说。
