根本解决办法是停机重建实例，将数据从共享表空间ibdata1迁出；需先验证innodb_file_per_table=0及ibdata1远大于实际数据量，再执行导出、清空、重配、导入并逐表alter table重建。
根本解决办法是重建实例，把数据从共享表空间（ibdata1）迁出。这不是调个参数、跑条命令就能收效的操作，因为 innodb_file_per_table=OFF 时，所有表、回滚段、undo 日志、数据字典都混在 ibdata1 里，删库删表甚至 OPTIMIZE 都不释放文件系统空间。
确认当前状态
先验证是否真被这个问题困扰：
- 执行 SELECT @@innodb_file_per_table; —— 返回 0 就是关着的
- 查 ibdata1 大小：ls -lh /var/lib/mysql/ibdata1，再对比 SELECT SUM(data_length + index_length) FROM information_schema.tables WHERE engine='InnoDB';，如果前者远大于后者，基本就是它了
- 删完大量数据后磁盘使用率没降，df 看不到变化，也是典型表现
停机重建：唯一安全缩容路径
必须停 MySQL 服务，导出→清空→重配→导入。过程不可逆，务必提前完整备份：
- 用 mysqldump --all-databases --no-tablespaces --skip-triggers --routines 导出（排除 triggers/routines 可选，但推荐带上）
- 停 MySQL：systemctl stop mysql 或对应服务命令
- 删掉 /var/lib/mysql/ibdata1、ib_logfile*、ibtmp1（注意：只删这几个文件，别删整个 data 目录）
- 编辑 my.cnf，在 [mysqld] 段确保：
innodb_file_per_table = ON
innodb_data_file_path = ibdata1:12M:autoextend - 启动 MySQL，它会自动生成最小化的 ibdata1（仅存元数据）
- 导入 dump 文件；导入完成后，对所有非系统表执行 ALTER TABLE tbl_name ENGINE=InnoDB;（强制重建，确保真正落到 .ibd 文件）
迁移后防止复发
重建不是终点，后续管理要跟上：
- 所有新表自动走独立表空间，但老表不会自动迁移——导入后那一步 ALTER TABLE ... ENGINE=InnoDB 很关键
- 定期检查：SELECT table_name, file_format FROM information_schema.innodb_sys_tables WHERE name LIKE 'db_name/%';，确认 file_format 是 Barracuda（现代格式），且表名对应路径下存在 .ibd 文件
- 监控大表增长：SELECT table_schema, table_name, round((data_length+index_length)/1024/1024, 2) size_mb FROM information_schema.tables WHERE engine='InnoDB' ORDER BY size_mb DESC LIMIT 10;
- 避免误操作：不要手动 touch、truncate、rm ibdata1；不要在未确认引擎时建表（CREATE TABLE t1 (...) ENGINE=InnoDB; 必须显式写）
这个过程需要计划停机窗口，不适合 7×24 高可用场景。若无法停机，只能临时扩容磁盘、清理无用库表、归档历史数据来缓解，但治标不治本。
