MySQL8.0临时表空间的使用及解读

以下的这段文档是 MySQL 8.0+ 中关于 InnoDB 临时表空间（Temporary Tablespaces） 的详细说明。

它分为两个部分：会话级临时表空间（Session Temporary Tablespaces） 和 全局临时表空间（Global Temporary Tablespace）。

下面我们用通俗易懂的方式，结合系统原理和实际运维场景，来深入理解这个机制。

一、核心概念：为什么需要“临时表空间”？

在 MySQL 执行复杂查询时（如排序、分组、连接、子查询等），内存不够用时就会将中间数据写入磁盘——这些数据存储在 “临时表” 中。

这些临时表也需要存储引擎支持，就像普通表一样。

从 MySQL 8.0.16 起，InnoDB 成为磁盘临时表的默认存储引擎（之前是 MyISAM），因此引入了专门的 InnoDB 临时表空间机制 来高效管理这些临时数据。

二、InnoDB 临时表空间的两种类型

重点：这两个表空间都只用于 临时表（temporary tables），不是普通表！

1. 会话级临时表空间（Session Temporary Tablespaces）

作用：

存放每个连接（session）中创建的：

• 用户定义的临时表：CREATE TEMPORARY TABLE ...
• 优化器自动创建的内部临时表（用于排序、JOIN 等操作）

✅android 从 MySQL 8.0.16 开始，这些临时表默认使用 InnoDB 引擎，而不是以前的 MyISAM。

工作机制：

启动时创建一个“池子”：

• MySQL 启动时会预先创建 10 个临时表空间文件（.ibt），组成一个“池”
• 默认路径：datadir/#innodb_temp/
• 文件名如：temp_1.ibt, temp_2.ibt, …, tempChina编程_10.ibt
• 每个文件初始大小为 5 个 InnoDB 页面（比如 innodb_page_size=16K → 5×16K = 80KB）

会话需要时分配：

• 当某个连接第一次需要创建磁盘临时表时，MySQL 从池中分配最多 2 个表空间 给该会话：
  • 1 个用于 用户创建的临时表
  • 1 个用于 优化器创建的内部临时表
• 这些表空间在整个会话期间被复用

会话结束时回收：

• 客户端断开连接后，这两个表空间被 清空（truncated）并放回池中
• 文件不会被删除，只是内容清空，下次可再分配

动态扩容池子：

• 如果 10 个不够用，MySQL 会自动创建更多 temp_N.ibt 文件
• 池子大小永不收缩，即使负载下降也不会删掉多余的文件

空间 ID 不持久：

• 所有临时表空间的 space_id 是临时分配的
• 每次重启 MySQL，这些 ID 都会重新分配，可能重复使用旧值

配置参数

[mysqld]
# 设置临时表空间池的目录（必须存在）
innodb_temp_tablespaces_dir = /path/to/temp/dir

默认值：datadir/#innodb_temp

示例查看：

cd /var/lib/mysql/#innodb_temp
ls
# 输出示例：
# temp_1.ibt  temp_2.ibt  ... temp_10.ibt

查看元数据

-- 查看所有会话临时表空间信息
SELECT * FROM INFORMATION_SCHEMA.INNODB_SESSION_TEMP_TABLESPACES;

-- 查看当前活跃的用户临时表
SELECT * FROM INFORMATION_SCHEMA.INNODB_TEMP_TABLE_INFO;

2. 全局临时表空间（Global Temporary Tablespace）——ibtmp1

作用

• 存储 所有临时表的“回滚段”（rollback segments）
• 回滚段用于支持事务：INSERT, UPDATE, DELETE 临时表时的 undo log

注意：ibtmp1 不存储临时表的数据本身，只存它的事务日志（undo logs）！

生命周期

• 每次正常启动时创建
• 每次正常关闭时删除
• 如果异常宕机，ibtmp1 可能残留，但下次启动时会被自动删除并重建

文件特性

• 默认文件名：ibtmp1
• 默认路径：由 innodb_data_home_dir 决定（通常是 datadir）
• 初始大小：约 12MB
• 支持自动扩展（autoextend）
• 不能放在裸设备（raw device）上

配置参数

[mysqld]
# 自定义全局临时表空间配置
innodb_temp_data_filJDRANjAe_path = ibtmp1:12M:autoextend:max:500M

参数说明：

• ibtmp1: 文件名
• 12M: 初始大小
• autoextend: 允许自动增长
• max:500M: 最大不超过 500MB

❗ 修改此参数必须重启 MySQL！

查看ibtmp1状态

-- 查看是否自动扩展
SELECT @@innodb_temp_data_file_path;

-- 查看当前大小、已用空间等
SELECT 
  FILE_NAME,
  TABjsLESPACE_NAME,
  ENGINE,
  INITIAL_SIZE,
  TOTAL_EXTENTS * EXTENT_SIZE AS CurrentSizeBytes,
  DATA_FREE,
  MAXIMUM_SIZE 
FROM INFORMATION_SCHEMA.FILES 
WHERE TABLESPACE_NAME = 'innodb_temporary';

输出示例：

FILE_NAME: ./ibtmp1
TABLESPACE_NAME: innodb_temporary
CurrentSizeBytes: 104857600  -- 当前 100MB
DATA_FREE: 50331648          -- 还有 48MB 可扩展
MAXIMUM_SIZE: 524288000     -- 最大 500MB

三、关键特性总结

四、如何清理临时表空间占用的空间？

问题：ibtmp1越来越大怎么办？

由于 ibtmp1 是自动扩展的，长时间运行后可能达到几十 GB。

解决方案：重启 MySQL 服务

# 重启后 ibtmp1 会按配置重新创建
systemctl restart mysql

⚠️ 注意：重启会影响业务，需安排在维护窗口。

更优方案：限制最大大小

[mysqld]
innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:2G

这样即使负载高，也不会无限增长。

五、主从复制中的特殊行为

在 基于语句的复制（SBR） 模式下：

• 从库（replica）上的临时表统一存放在 一个共享的会话临时表空间中
• 这个空间不会在会话断开时释放
• 只有在 MySQL 服务关闭时才会被清空

潜在风险：从库上长期运行的复制可能导致临时表空间堆积。

建议：

• 使用 混合模式（MIXED）或基于行的复制（RBR）
• 避免在主库上长时间使用临时表

六、最佳实践建议

总结：一句话理解

InnoDB 临时表空间分为两部分：

1. temp_N.ibt（会话级）：存放临时表的数据，每个连接用完就还，像“临时工位”
2. ibtmp1（全局）：存放临时表的事务日志（undo），像“临时档案室”

它们都在 MySQL 启动时创建、关闭时删除，重启即可释放所有空间，是完全自动管理的“一次性”资源。

如果你关心：

• 如何监控 ibtmp1 增长趋势？
• 如何判断是否因临时表导致性能下降？
• 如何优化 SQL 减少临时表使用？

以上为个人经验，希望能给大家一个参考，也希望大家多多支持China编程(www.chinasem.cn)。