ibdata1无法在线收缩是InnoDB设计限制，唯一安全缩容方式是停机导出、清空数据目录、启用innodb_file_per_table后初始化新实例并导入。

升级 MySQL 8.0 后 ibdata1 疯涨，不是配置漏了、也不是操作错了，是 InnoDB 共享表空间的设计限制——它根本不能在线收缩。你看到的“暴涨”，大概率是老库没启用 innodb_file_per_table，所有表数据都堆在 ibdata1 里，升级后只是让问题暴露得更彻底。

怎么确认真是 ibdata1 在撑爆磁盘？

别急着删文件或调参数，先验证根源：

• 运行 SELECT @@innodb_file_per_table; —— 如果返回 0，说明所有 InnoDB 表都还在共享表空间，后续任何 OPTIMIZE TABLE 或 ALTER TABLE ENGINE=InnoDB 都不会缩小 ibdata1
• 对比物理大小和逻辑数据量：ls -lh /var/lib/mysql/ibdata1 vs SELECT SUM(data_length + index_length) FROM information_schema.tables WHERE engine='InnoDB'; —— 若前者远大于后者（比如 50G vs 6G），基本锁定是共享表空间膨胀
• 查表实际存放位置：SELECT table_name, file_format FROM information_schema.innodb_sys_tables WHERE name LIKE 'your_db/%'; —— 结果中若无 .ibd 字段，说明该表仍驻留在 ibdata1

ALTER TABLE ENGINE=InnoDB 为什么没用？

这个命令常被误认为能缩 ibdata1，其实它只对已启用 innodb_file_per_table = ON 的表起作用：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 执行前必须确保磁盘剩余空间 ≥ 当前表 data_length + index_length 的 2 倍——临时表和原表会同时存在
• 它本质是重建表并重写数据页，等价于 OPTIMIZE TABLE，但语义更明确；MySQL 5.6+ 支持 ALGORITHM=INPLACE 减少锁时间（注意：不是所有 DDL 都支持）
• 执行后检查 SELECT data_free FROM information_schema.tables WHERE table_name='your_table'; —— 应显著下降或归零；若没变化，大概率有长事务钉住旧页（trx_state = 'RUNNING' AND trx_query IS NULL）

停机重建是唯一安全路径

别信“mv ibdata1 && 重启自动生成”的说法——那等于放弃全部数据，不是清理，是重装：

• 先导出全库：mysqldump --all-databases --single-transaction --routines --triggers > full_backup.sql（大库优先用 mydumper）
• 停 MySQL，完整备份旧 /var/lib/mysql 目录（不只是 ibdata1，含 mysql/ 系统库、ib_logfile*、undo*）
• 清空 /var/lib/mysql，并在 my.cnf 中显式写入：innodb_file_per_table = ON
• 初始化新实例：mysqld --initialize --datadir=/var/lib/mysql --innodb_file_per_table=ON；启动后立即执行 SET GLOBAL innodb_file_per_table = ON;
• 导入时加字符集参数：mysql -u root -p --default-character-set=utf8mb4

真正麻烦的不是操作本身，而是重建期间业务中断窗口，以及导出/导入过程中字符集、时区、GTID 等隐性依赖容易被忽略。一旦跳过完整备份或漏掉系统库，实例很可能无法启动。