mysql怎么使用临时表,mysql的临时表

MySQL如何使用临时表

解决办法：

江陵ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景，ssl证书未来市场广阔！成为成都创新互联的ssl证书销售渠道，可以享受市场价格4-6折优惠！如果有意向欢迎电话联系或者加微信：18982081108（备注：SSL证书合作）期待与您的合作！

当临时表不存在时，将查询结果保存在临时表中：

CREATE TEMPORARY TABLE tmp_table SELECT * FROM table_name；

我的具体代码是

CREATE temporary table tmp

(SELECT t1.pid a, t1.pname b,t2.pid c, t2.pdescribe d FROM

(SELECT pid,pname FROM admin_advert_place WHERE pid IN (3,4,5,6,7)) t1 LEFT JOIN

(SELECT pid,pdescribe FROM admin_advert_place

WHERE pgid IN (6,7,8)) t2 ON t1.pid = t2.pid)

技术分享 | 浅谈 MySQL 的临时表和临时文件

本文内容来源于对客户的三个问题的思考：

以下测试都是在 MySQL 8.0.21 版本中完成，不同版本可能存在差异，可自行测试；

临时表和临时文件都是用于临时存放数据集的地方；

一般情况下，需要临时存放在临时表或临时文件中的数据集应该符合以下特点：

从临时表|临时文件产生的主观性来看，分为2类：

用户创建临时表：

  -- 用户创建临时表(只有创建临时表的会话才能查看其创建的临时表的内容)

  注意：

  可以创建和普通表同名临时表，其他会话可以看到普通表(因为看不到其他会话创建的临时表)；

  创建临时表的会话会优先看到临时表；

  -- 同名表的创建的语句如下

  当存在同名的临时表时，会话都是优先处理临时表(而不是普通表)，包括：select、update、delete、drop、alter 等操作；

查看用户创建的临时表：

  任何 session 都可以执行下面的语句；

  查看用户创建的当前 active 的临时表(不提供 optimizer 使用的内部 InnoDB 临时表信息)

  注意

  用户创建的临时表，表名为t1，

  但是通过 INNODB_TEMP_TABLE_INFO 查看到的临时表的 NAME 是#sql开头的名字，例如：#sql45aa_7c69_2 ；

  另外 information_schema.tables 表中是不会记录临时表的信息的。

用户创建的临时表的回收：

用户创建的临时表的其他信息参数：

  会话临时表空间存储 用户创建的临时表和优化器 optimizer 创建的内部临时表(当磁盘内部临时表的存储引擎为 InnoDB 时)；

  innodb_temp_tablespaces_dir 变量定义了创建 会话临时表空间的位置，默认是数据目录下的#innodb_temp 目录；

  文件类似temp_[1-20].ibt ；

  查看会话临时表空间的元数据：

  用户创建的临时表删除后，其占用的空间会被释放(temp_[1-20].ibt文件会变小)。

  在 MySQL 8.0.16 之前，internal_tmp_disk_storage_engine 变量定义了用户创建的临时表和 optimizer 创建的内部临时表的引擎，可选 INNODB 和 MYISAM ；

  从 MySQL 8.0.16 开始，internal_tmp_disk_storage_engine参数被移除，默认使用InnoDB存储引擎；

  innodb_temp_data_file_path 定义了用户创建的临时表使用的回滚段的存储文件的相对路径、名字、大小和属性，该文件是全局临时表空间(ibtmp1)；

  可以使用语句查询全局临时表空间的数据文件大小：

SQL 什么时候产生临时表|临时文件呢？

  需要用到临时表或临时文件的时候，optimizer 自然会创建使用(感觉是废话，但是又觉得有道理=.=!)；

  (想象能力强的，可以牢记上面这句话；想象能力弱的，只能死记下面的 SQL 了。我也弱，此处有个疲惫的微笑????)

下面列举一些 server 在处理 SQL 时，可能会创建内部临时表的 SQL ：

  SQL 包含 union | union distinct 关键字

  SQL 中存在派生表

  SQL 中包含 with 关键字

  SQL 中的order by 和 group by 的字段不同

  SQL 为多表 update

  SQL 中包含 distinct 和 order by 两个关键字

我们可以通过下面两种方式判断 SQL 语句是否使用了临时表空间：

  # 如果 explain 的 Extra 列包含 Using temporary ，那么说明会使用临时空间，如果包含 Using filesort ，那么说明会使用文件排序(临时文件)；

  如果执行 SQL 后，表的 ID 列变为了show processlist 中的 id 列的值，那么说明 SQL 语句使用了临时表空间

SQL创建的内部临时表的存储信息：

  SQL 创建内部临时表时，优先选择在内存中，默认使用 TempTable 存储引擎(由参数 internal_tmp_mem_storage_engine 确定)，

  当 temptable 使用的内存量超过 temptable_max_ram 定义的大小时，

  由 temptable_use_mmap 确定是使用内存映射文件的方式还是 InnoDB 磁盘内部临时表的方式存储数据

  (temptable_use_mmap 参数在 MySQL 8.0.16 引入，MySQL 8.0.26 版本不推荐，后续应该会移除)；

  temptable_use_mmap 的功能将由MySQL 8.0.23 版本引入的 temptable_max_mmap 代替，

  当 temptable_max_mmap=0 时，说明不使用内存映射文件，等价于 temptable_use_mmap=OFF ；

  当 temptable_max_mmap=N 时，N为正整数，包含了 temptable_use_mmap=ON 以及声明了允许为内存映射文件分配的最大内存量。

  该参数的定义解决了这些文件使用过多空间的风险。

  内存映射文件产生的临时文件会存放于 tmpdir 定义的目录中，在 TempTable 存储引擎关闭或 mysqld 进程关闭时，回收空间；

  当 SQL 创建的内部临时表，选择 MEMORY 存储引擎时，如果内存中的临时表变的太大，MySQL 将自动将其转为磁盘临时表；

  其能使用的内存上限为 min(tmp_table_size,max_heap_table_size)；

监控 TempTable 从内存和磁盘上分配的空间：

  具体的字段含义见：Section 27.12.20.10, “Memory Summary Tables”.

监控内部临时表的创建：

  当在内存或磁盘上创建内部临时表，服务器会增加 Created_tmp_tables 的值；

  当在磁盘上创建内部临时表时，服务器会增加 Created_tmp_disk_tables 的值，

  如果在磁盘上创建了太多的内部临时表，请考虑增加 tmp_table_size 和 max_heap_table_size 的值；

  created_tmp_disk_tables 不计算在内存映射文件中创建的磁盘临时表；

例外项：

  临时表/临时文件一般较小，但是也存在需要大量空间的临时表/临时文件的需求：

因为这些例外项一般需要较大的空间，所以需要考虑是否要将其存放在独立的挂载点上。

其他：

  列出由失败的 alter table 创建的隐藏临时表，这些临时表以#sql开头，可以使用 drop table 删除；

  通过 lsof +L1 可以查看标识为 delete ，但还未释放空间的文件。

   如果想释放这些 delete 状态的文件，可以尝试下面的方法(不推荐，后果自负)：

普通的磁盘临时表|临时文件(一般需要较小的空间)：

  临时表|临时文件的一般所需的空间较小，会优先存放于内存中，若超过一定的大小，则会转换为磁盘临时表|临时文件；

  磁盘临时表默认为 InnoDB 引擎，其存放在临时表空间中，由 innodb_temp_tablespaces_dir 定义表空间的存放目录，表空间文件类似：temp_[1-20].ibt ；MySQL 未定义 InnoDB 临时表空间的最大使用上限；

  当临时表|临时文件使用完毕后，会自动回收临时表空间文件的大小；

  innodb_temp_data_file_path 定义了用户创建的临时表使用的回滚段的存储文件的相对路径、名字、大小和属性，该文件是全局临时表空间(ibtmp1)，该文件可以设置文件最大使用大小；

例外项(一般需要较大的空间)：

  load data local 语句，客户端读取文件并将其内容发送到服务器，服务器将其存储在 tmpdir 参数指定的路径中；

  在 replica 中，回放 load data 语句时，需要将从 relay log 中解析出来的数据存储在 slave_load_tmpdir(replica_load_tmpdir) 指定的目录中，该参数默认和 tmpdir 参数指定的路径相同；

  需要 rebuild table 的在线 alter table 需要使用 innodb_tmpdir 存放排序磁盘排序文件，如果 innodb_tmpdir 未指定，则使用 tmpdir 的值；

若用户判断产生的临时表|临时文件一定会转换为磁盘临时表|临时文件，那么可以设置 set session big_tables=1;让产生的临时表|临时文件直接存放在磁盘上；

  对于需要较小空间的临时表|临时文件，MySQL 要么将其存储于内存，要么放在统一的磁盘临时表空间中，用完即释放；

  对于需要较大空间的临时表|临时文件，可以通过设置参数，将其存储于单独的目录|挂载点；例如：load local data 语句或需要重建表的在线 alter table 语句，都有对应的参数设置其存放临时表|临时文件的路径；

  当前只有 innodb_temp_data_file_path 参数可以限制 用户创建的临时表使用的回滚段的存储文件的大小，无其他参数可以限制临时表|临时文件可使用的磁盘空间；

mysql是怎样使用内部临时表的

我们仍使用 实验 05 中的环境，略去准备数据的过程。

我们仍然使用两个会话，一个会话 run，用于运行主 SQL；另一个会话 ps，用于进行 performance_schema 的观察：

主会话线程号为 29，

将 performance_schema 中的统计量重置，

临时表的表大小限制取决于参数  tmp_table_size 和 max_heap_table_size 中较小者，我们实验中以设置 max_heap_table_size 为例。

我们将会话级别的临时表大小设置为 2M（小于上次实验中临时表使用的空间），执行使用临时表的 SQL：

查看内存的分配记录：

会发现内存分配略大于 2M，我们猜测临时表会比配置略多一点消耗，可以忽略。

查看语句的特征值：

可以看到语句使用了一次需要落磁盘的临时表。

那么这张临时表用了多少的磁盘呢？

我们开启 performance_schema 中 waits 相关的统计项：

重做实验，略过。

再查看 performance_schema 的统计值：

可以看到几个现象：

1. 临时表空间被写入了 7.92MiB 的数据。

2. 这些数据是语句写入后，慢慢逐渐写入的。

来看看这些写入操作的特征，该方法我们在 实验 03 使用过：

可以看到写入的线程是 page_clean_thread，是一个刷脏操作，这样就能理解数据为什么是慢慢写入的。

也可以看到每个 IO 操作的大小是 16K，也就是刷数据页的操作。

结论：

我们可以看到，

1. MySQL 会基本遵守 max_heap_table_size 的设定，在内存不够用时，直接将表转到磁盘上存储。

2. 由于引擎不同（内存中表引擎为 heap，磁盘中表引擎则跟随 internal_tmp_disk_storage_engine 的配置），本次实验写磁盘的数据量和 实验 05 中使用内存的数据量不同。

3. 如果临时表要使用磁盘，表引擎配置为 InnoDB，那么即使临时表在一个时间很短的 SQL 中使用，且使用后即释放，释放后也会刷脏页到磁盘中，消耗部分 IO。