ibdata1无法收缩是因为innodb不支持共享表空间缩容，undo日志持续写入且默认不分离；安全清理需重建实例：停库→启用innodb_file_per_table→初始化→导入数据。
ibdata1 为什么越用越大且无法收缩
ibdata1 是 InnoDB 的共享表空间文件，默认存放数据字典、undo 日志、插入缓冲、双写缓冲等元数据和系统结构。它一旦增长，MySQL 就不会自动回收或缩小——哪怕你删掉了大量表或执行了 OPTIMIZE TABLE，ibdata1 体积也基本不变。
根本原因是：InnoDB 不支持 shrink 共享表空间；所有 undo 日志和回滚段都持续写入其中，尤其在长事务、高并发更新场景下，undo 段堆积严重，ibdata1 就会持续膨胀。
- 启用
innodb_file_per_table=ON后，新创建的表数据会存到独立.ibd文件中，但ibdata1仍承担系统级职责，不会变小 - 如果早期没开
innodb_file_per_table，老表的数据和索引全挤在ibdata1里，迁移成本极高 - MySQL 5.6+ 支持
innodb_undo_log_truncate=ON+innodb_undo_tablespaces配合，才能让 undo 日志定期轮转并截断，但前提是 undo 已分离为独立表空间（默认不启用）
binlog 和 relay log 不清理会悄悄吃光磁盘
MySQL 默认开启 binlog（主从复制、恢复必备），但不会自动删除旧日志——除非你明确配置了 expire_logs_days 或 binlog_expire_logs_seconds（MySQL 8.0.11+）。未配置时，binlog 文件会一直累积，尤其在高写入业务中，单日可能生成数 GB。
同理，从库上的 relay log（由 IO_THREAD 写入）若没启用 relay_log_purge=ON（默认是 ON），或被 SQL_THREAD 卡住未及时重放，也会堆积不清理。
- 检查当前 binlog 大小：
SHOW BINARY LOGS;，再用ls -lh /var/lib/mysql/mysql-bin.*看物理体积 - 临时清理：
PURGE BINARY LOGS BEFORE '2024-01-01 00:00:00';，但生产环境建议先确认从库已同步完毕 - 永久生效：在
my.cnf中加expire_logs_days = 7（或更短），重启 MySQL 或执行SET GLOBAL binlog_expire_logs_seconds = 604800;
如何安全释放 ibdata1 占用的空间
直接删 ibdata1 会导致 MySQL 启动失败——它不是普通日志，而是 InnoDB 的“心脏文件”。唯一安全收缩它的办法是重建整个实例，本质是导出 + 重装 + 导入。
- 前提：确保有完整逻辑备份（
mysqldump或mydumper），且业务可停机或接受主从切换 - 步骤简述：停库 → 备份原数据目录 → 修改配置启用
innodb_file_per_table=ON和innodb_undo_tablespaces=2（如需 undo 分离）→ 初始化新实例（mysqld --initialize）→ 启动空实例 → 导入数据 - 注意：导入后，原
ibdata1里的 undo/系统表信息已丢失，但新实例会重建；历史 binlog 若需保留，得单独归档，不能依赖原文件
监控与预防：别等磁盘 100% 才发现
磁盘满通常不是突发问题，而是缓慢积累的结果。靠人工查 df -h 很被动，必须把关键路径纳入监控项：
- 监控目录：
/var/lib/mysql/（数据）、/var/lib/mysql/mysql-bin.*（binlog）、/var/lib/mysql/relay-log.*（relay log） - 查 innodb 表空间使用：
SELECT FILE_NAME, TABLESPACE_NAME, ENGINE, TOTAL_EXTENTS*EXTENT_SIZE AS TotalSize FROM information_schema.FILES WHERE FILE_TYPE='DATAFILE'; - 检查 long transaction：
SELECT * FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED LIMIT 5;，长时间未提交的事务会阻止 undo 清理
真正难处理的是那些没被显式暴露的隐性增长点——比如没配 expire_logs_days 的 binlog、长期不清理的 slow log（如果启用了 slow_query_log_file 并指向同一磁盘）、或者第三方工具（如 pt-archiver）产生的临时 dump 文件。这些往往比 ibdata1 更容易被忽略，也更容易失控。
