ibdata1无法收缩是InnoDB设计限制，唯一安全缩容方式是停机导出、初始化新实例并启用innodb_file_per_table；独立.ibd文件需ALTER TABLE ENGINE=InnoDB重建释放空间。
InnoDB 表空间不会自动收缩是设计使然，不是故障；DELETE、TRUNCATE、OPTIMIZE 都无法缩小 ibdata1，对独立 .ibd 文件也必须显式重建才能释放磁盘空间。
确认是不是 ibdata1 共享表空间真撑爆了
别急着执行 OPTIMIZE 或删日志，先验证根源：如果所有表都挤在 ibdata1 里，后续所有“收缩”操作都只是内部整理，文件大小纹丝不动。
- 执行
SELECT @@innodb_file_per_table;—— 返回0就说明共享模式开着，老表全在 ibdata1 中 - 对比物理大小和逻辑数据量：
ls -lh /var/lib/mysql/ibdata1vsSELECT SUM(data_length + index_length) FROM information_schema.tables WHERE engine='InnoDB';；若前者远大于后者（比如 80G vs 12G），基本锁定是共享表空间膨胀 - 查
information_schema.INNODB_SYS_TABLES：SELECT table_name, file_format FROM information_schema.innodb_sys_tables WHERE name LIKE 'your_db/%';；结果中若没出现.ibd路径字段，说明该表没走独立表空间
收缩单个 .ibd 文件：ALTER TABLE ENGINE=InnoDB 是首选
这是最常用、最可控的收缩方式，本质是重建表并重写数据页，消除空洞、压缩存储。它比 OPTIMIZE TABLE 语义更明确，且兼容性更好。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 执行前确保磁盘剩余空间 ≥ 当前表
data_length + index_length的 2 倍——临时表和原表会同时存在 - 该操作加元数据锁（MDL），期间所有 DDL（如
DROP DATABASE、CREATE INDEX）都会被阻塞；大表务必避开高峰期 - 执行后立即检查：
SELECT data_free FROM information_schema.tables WHERE table_name='your_table';应归零或显著下降；若没变化，大概率有长事务钉住旧页（trx_state = 'RUNNING'且trx_query IS NULL） - 注意：TRUNCATE 后
.ibd大小不变是正常行为，必须跟一步ALTER TABLE your_table ENGINE=InnoDB才能真正释放空间
处理顽固的 ibdata1 过大：停机导出 → 初始化新实例 → 导入是唯一安全路径
ibdata1 一旦膨胀就无法在线 shrink——它承载数据字典、undo 日志、回滚段等系统级内容，MySQL 不支持共享表空间缩容。别碰文件本身，直接删会导致 MySQL 拒绝启动。
- 先导出全库：
mysqldump --all-databases --single-transaction --routines --triggers > full_backup.sql（库大时优先用mydumper） - 停 MySQL，备份旧数据目录（含
ibdata1、ib_logfile*、undo*），再清空/var/lib/mysql/ - 初始化新实例：
mysqld --initialize --datadir=/var/lib/mysql，确保配置中已启用innodb_file_per_table = ON - 导入前检查新实例的
SELECT @@innodb_file_per_table;必须返回1；否则导入后老问题照旧
Undo 表空间过大时别只盯着 innodb_undo_log_truncate
这个变量只是“允许截断”，不等于“立刻释放磁盘空间”。即使成功触发 truncate，du -h undo001 看到的大小也不会变——它只做逻辑清空，LSN 归零，但文件分配块未回收。
- 先确认
SHOW VARIABLES LIKE 'innodb_undo_tablespaces';返回值 ≥ 2；若为 0，说明 undo 全挤在 ibdata1 里，innodb_undo_log_truncate根本不生效 - MySQL 8.0.30+ 可用
OPTIMIZE TABLESPACE undo001;真正释放磁盘空间（需 purge 完成且表空间处于 active 状态） - 低于 8.0.30 的版本，唯一办法是停库 → 删除
undo001→ 重启让 MySQL 重建初始大小（默认 10MB）的文件；但必须提前设好innodb_fast_shutdown = 0并确认无活跃事务 - 别忽略长事务影响：
SELECT * FROM information_schema.INNODB_TRX ORDER BY trx_started LIMIT 5;中运行超 30 分钟、trx_query IS NULL的记录，必须KILL，否则 purge 卡死，undo 永远无法清理
真正难的不是操作步骤，而是判断哪一层在膨胀：ibdata1？某个 .ibd？还是 undo 表空间？三者收缩路径完全不同，混用方案只会浪费时间甚至引发故障。每次动手前，先跑一遍 SELECT @@innodb_file_per_table; 和 ls -lh /var/lib/mysql/ 对比，比盲目 OPTIMIZE 有用十倍。
