不能直接缩小ibdata1，唯一方法是全库导出后重建实例；innodb_file_per_table=1仅影响新表，旧表及系统元数据、undo日志等始终留在ibdata1中，且无法在线清理。
不能直接 shrink ibdata1，必须重建实例；开启 innodb_file_per_table 只对新表生效，旧表仍留在 ibdata1 里。
为什么 innodb_file_per_table=1 不能缩小现有 ibdata1
这个参数控制的是「新建表是否使用独立表空间」，不是「把已有表从共享空间搬出来」。一旦表创建时 innodb_file_per_table 是 OFF（默认），它的数据和索引就永久写入 ibdata1，后续即使改配置、重启、OPTIMIZE TABLE，也不会移出——OPTIMIZE TABLE 对共享表空间的表只做页整理，不释放空间回操作系统。
- ibdata1 里还存着全局结构：数据字典、undo 日志段、change buffer、双写缓冲区、回滚段等，这些内容随事务增长持续写入，且无法在线清理
- 即使你 DROP 所有用户表，ibdata1 也不会变小，因为系统元数据和历史 undo 仍保留
- MySQL 不提供任何命令能把某张表从 ibdata1 “导出”到 .ibd 文件
真正能缩小 ibdata1 的唯一方法：全库导出 + 重装实例
这不是“优化”，而是重建。整个过程会中断服务，且必须确保备份完整、时间窗口充足。
- 用
mysqldump -u root -p --all-databases --single-transaction --routines --triggers > full.sql导出（--single-transaction避免锁表） - 停库：
systemctl stop mysqld（或mysqladmin -uroot -p shutdown） - 删除
ibdata1、ib_logfile*、ibtmp1（注意：不是删 data 目录，只删这几个文件） - 在
my.cnf的[mysqld]段明确写入：innodb_file_per_table=1，并确认没有残留的innodb_data_file_path自定义配置 - 启动 MySQL，它会自动重建干净的 ibdata1（默认 12MB）和日志文件
- 导入：
mysql -u root -p —— 此时所有新表都落在各自的 <code>.ibd文件中
误操作后 ibdata1 膨胀过快？先堵住源头
如果 ibdata1 在短期内暴涨（比如从 1GB 突增到 50GB），大概率是大量长事务、未提交的 delete/update 或大事务回滚导致 undo 日志堆积。此时别急着重建，先止损：
- 查活跃长事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), TRX_STARTED)) > 60; - 限制 undo 日志保留时间（MySQL 5.7+）：
SET GLOBAL innodb_undo_log_truncate = ON;+SET GLOBAL innodb_max_undo_log_size = 1073741824;（1GB） - 检查是否误设了
innodb_log_file_size过小，导致 checkpoint 频繁触发刷脏页压力，间接加剧 ibdata1 写入 - 临时禁止大事务：应用层加事务超时，或数据库侧用
max_execution_time限流
重建后仍要警惕的三个细节
很多人做完重建以为一劳永逸，结果几个月后 ibdata1 又开始缓慢爬升——问题往往出在被忽略的系统表和配置上。
- MySQL 系统库（
mysql、performance_schema、information_schema）里的 InnoDB 表（如innodb_table_stats）仍强制使用共享表空间，它们的数据增长不可控 - 没关掉
innodb_undo_tablespaces（MySQL 5.6+ 默认 ON），会导致额外生成undo001、undo002等文件，它们也属于“共享空间体系”的一部分 - 备份脚本里漏了
--skip-triggers或--skip-routines，导致恢复时触发器/存储过程重建失败，部分元数据异常写入 ibdata1
ibdata1 的“不可收缩性”是 InnoDB 架构决定的硬限制，不是配置疏漏。想彻底规避，唯一可持续的做法是：新实例默认开启 innodb_file_per_table，并把大表拆分、定期归档、避免单事务修改百万行。
