ibtmp1膨胀后无法在线收缩，唯一有效方式是停库删除文件并重启，使其按innodb_temp_data_file_path配置重建；该参数仅启动时读取，需写入my.cnf的[mysqld]段，推荐配置为ibtmp1:50M:autoextend:max:2G。
临时表空间 ibtmp1 膨胀后无法收缩，必须停库重置
MySQL 8.0 的 ibtmp1 文件一旦增长，运行中不会自动缩容——哪怕所有临时表都已释放、连接全部断开。这是最常被误判的点：监控看到磁盘占用高，查 information_schema.INNODB_TEMP_TABLE_INFO 却显示空，仍不能说明空间已回收。
真正有效的清理方式只有一种：彻底停止 MySQL（systemctl stop mysqld），手动删除 ibtmp1（它位于 datadir 目录下，不是子目录），再启动服务。重启后会按 innodb_temp_data_file_path 配置重建，回到初始大小。
-
innodb_temp_data_file_path必须写在my.cnf的[mysqld]段，且仅在启动时读取，SET GLOBAL无效 - 推荐配置示例：
innodb_temp_data_file_path = ibtmp1:50M:autoextend:max:2G—— 初始 50MB 避免频繁扩展，:max:2G是硬性保护，防止撑爆磁盘 - 不要省略
:autoextend，否则空间用尽会直接报错Internal temporary table is full
会话级临时表空间（temp_N.ibt）无需手动干预，但要注意路径和数量
MySQL 8.0.16+ 默认启用会话级临时表空间，文件名形如 temp_1.ibt、temp_2.ibt… 存放在 datadir/#innodb_temp/ 下。它们由 MySQL 自动管理：会话断开即清空内容并归还池子，文件本身不删除。
你几乎不需要动它们，但有两个实际约束点：
- 默认预创建 10 个文件，若并发会话数极高（比如 >500），可能触发动态扩容，产生大量小文件——可通过调整
innodb_temp_tablespaces_dir指向更高 IOPS 的磁盘路径缓解 - 该目录不可与系统表空间或数据目录混用；若
#innodb_temp所在分区满，会导致任何需要磁盘临时表的查询失败，错误为Operating system error number 28 - 不能用
CREATE TABLESPACE或DROP TABLESPACE管理这些文件，它们是内部机制，无对应 SQL 接口
共享表空间（ibdata1）应尽量避免存放用户表数据
MySQL 8.0 中，ibdata1 仅保留 change buffer，不再存数据字典、undo 日志或用户表数据——前提是已启用 innodb_file_per_table=ON（8.0 默认开启）。但如果你在建表时显式指定 TABLESPACE = innodb_system，或历史遗留表未迁移，用户数据仍会落入其中。
后果很直接：删表或 TRUNCATE 后，ibdata1 文件大小完全不下降，也无法在线收缩。唯一办法是导出 + 停库 + 删除 ibdata1 + 重装初始化 + 导入——成本极高。
- 检查哪些表还在系统表空间：执行
SELECT NAME, SPACE_TYPE FROM INFORMATION_SCHEMA.INNODB_TABLES WHERE SPACE_TYPE = 'System' - 迁移方法：对单表执行
ALTER TABLE t1 TABLESPACE = innodb_file_per_table（需确保目标表无外键依赖） - 禁用隐式回退：在
my.cnf显式写死innodb_file_per_table=ON，避免某些客户端工具或 ORM 意外绕过
通用表空间（CREATE TABLESPACE）适合跨库共享或 IO 隔离，但不支持删文件
通用表空间是少数能手动创建、并指定路径的表空间类型，典型用于将高频访问的大表（如日志归档表）单独挂到 SSD 盘，或让多个数据库共用同一组物理文件以节省元数据内存。
但它有硬限制：一旦文件加入表空间，就不能从表空间里移除，也不能直接 rm 对应的 .ibd 文件——MySQL 启动时会校验，缺失则报错退出。
- 创建时路径必须绝对，且 MySQL 进程要有写权限：
CREATE TABLESPACE ts_log ADD DATAFILE '/ssd/mysql/ts_log.ibd' ENGINE=InnoDB; - 建表时绑定：
CREATE TABLE log_202609 (id BIGINT) TABLESPACE = ts_log; - 想“删除”数据文件？只能先
DROP TABLE所有归属该表空间的表，再DROP TABLESPACE ts_log—— 但前提是该表空间里没任何表，且 MySQL 8.0.23+ 支持该操作 - 表空间名大小写敏感，
ts_log和TS_LOG是两个不同对象
ibtmp1 和 ibdata1，一个膨胀后必须停机，一个膨胀后几乎无法挽回——日常监控不能只看总磁盘用量，得盯住这两个文件的实时大小变化。 
