一、临时表：

1、临时表和内存表的区别：

内存表，指的是使用Memory引擎的表，建表语法是create table … engine=memory;。这种表的数据都保存在内存里，系统重启的时候会被清空，但是表结构还在。除了这两个特性看上去比较“奇怪”外，从其他的特征上看，它就是一个正常的表。
临时表，可以使用各种引擎类型。如果是使用InnoDB引擎或者MyISAM引擎的临时表，写数据的时候是写到磁盘上的。当然，临时表也可以使用Memory引擎。

2、临时表的特征：

一个临时表只能被创建它的session访问，对其他线程不可见。所以，图中session A创建的临时表t，对于session B就是不可见的。
临时表只能被创建它的session访问，所以在这个session结束的时候，会自动删除临时表。
临时表可以与普通表同名。
session A内有同名的临时表和普通表的时候，show create语句，以及增删改查语句访问的是临时表。
show tables命令不显示临时表。

3、临时表适合join优化场景的原因：

不同session的临时表是可以重名的，如果有多个session同时执行join优化，不需要担心表名重复导致建表失败的问题。
不需要担心数据删除问题。如果使用普通表，在流程执行过程中客户端发生了异常断开，或者数据库发生异常重启，还需要专门来清理中间过程中生成的数据表。而临时表由于会自动回收，所以不需要这个额外的操作。

4、临时表的应用----分库分表系统的跨库查询：

将一个大表ht，按照字段f，拆分成1024个分表，然后分布到32个数据库实例上。

一般情况下，这种分库分表系统都有一个中间层proxy。不过，也有一些方案会让客户端直接连接数据库，也就是没有proxy这一层。
在这个架构中，分区key的选择是以“减少跨库和跨表查询”为依据的。如果大部分的语句都会包含f的等值条件，那么就要用f做分区键。这样，在proxy这一层解析完SQL语句以后，就能确定将这条语句路由到哪个分表做查询。

语句一：select v from ht where f=N;
语句二：select v from ht where k >= M order by t_modified desc limit 100;

对于语句一：可以通过分表规则（比如，N%1024)来确认需要的数据被放在了哪个分表上。这种语句只需要访问一个分表，是分库分表方案最欢迎的语句形式了。
对于语句二：由于查询条件里面没有用到分区字段f，只能到所有的分区中去查找满足条件的所有行，然后统一做order by 的操作。这种情况下，有两种比较常用的思路。
- 在proxy层的进程代码中实现排序。这种方式的优势是处理速度快，拿到分库的数据以后，直接在内存中参与计算。不过，这个方案的缺点也比较明显：
- 把各个分库拿到的数据，汇总到一个MySQL实例的一个表中，然后在这个汇总实例上做逻辑操作。对于语句二，执行流程可以类似这样：
  - 在汇总库上创建一个临时表temp_ht，表里包含三个字段v、k、t_modified；
  - 在各个分库上执行select v,k,t_modified from ht_x where k >= M order by t_modified desc limit 100;
  - 把分库执行的结果插入到temp_ht表中；
  - 执行select v from temp_ht order by t_modified desc limit 100;
  - 得到结果。
  - 执行流程图：
    
    注意：在实践中，每个分库的计算量往往都不饱和，所以会直接把临时表temp_ht放到32个分库中的某一个上。

5、临时表可以重名的原因：

<1>、原因一：

在执行语句

create temporary table temp_t(id int primary key)engine=innodb;

这个语句的时候，MySQL要给这个InnoDB表创建一个frm文件保存表结构定义，还要有地方保存表数据。这个frm文件放在临时文件目录下，文件名的后缀是.frm，前缀是“#sql{进程id}{线程id}序列号”。可以使用select @@tmpdir命令，来显示实例的临时文件目录。
关于表中数据的存放方式，在不同的MySQL版本中有着不同的处理方式：

在5.6以及之前的版本里，MySQL会在临时文件目录下创建一个相同前缀、以.ibd为后缀的文件，用来存放数据文件；
从 5.7版本开始，MySQL引入了一个临时文件表空间，专门用来存放临时文件的数据。因此，就不需要再创建ibd文件了。

从文件名的前缀规则，可以看到，其实创建一个叫作t1的InnoDB临时表，MySQL在存储上认为创建的表名跟普通表t1是不同的，因此同一个库下面已经有普通表t1的情况下，还是可以再创建一个临时表t1的。

图中这个进程的进程号是1234，session A的线程id是4，session B的线程id是5。所以可以看到，session A和session B创建的临时表，在磁盘上的文件不会重名。

<2>、原因二：

MySQL维护数据表：MySQL维护数据表，除了物理上要有文件外，内存里面也有一套机制区别不同的表，每个表都对应一个table_def_key。

一个普通表的table_def_key的值是由“库名+表名”得到的，所以如果你要在同一个库下创建两个同名的普通表，创建第二个表的过程中就会发现table_def_key已经存在了。
而对于临时表，table_def_key在“库名+表名”基础上，又加入了“server_id+thread_id”。
也就是说，session A和sessionB创建的两个临时表t1，它们的table_def_key不同，磁盘文件名也不同，因此可以并存。

<3>、原因三：

在实现上，每个线程都维护了自己的临时表链表。这样每次session内操作表的时候，先遍历链表，检查是否有这个名字的临时表，如果有就优先操作临时表，如果没有再操作普通表；在session结束的时候，对链表里的每个临时表，执行 “DROP TEMPORARY TABLE +表名”操作。

6、临时表的主备复制：

在主库上执行语句序列：

create table t_normal(id int primary key, c int)engine=innodb;/*Q1*/
create temporary table temp_t like t_normal;/*Q2*/
insert into temp_t values(1,1);/*Q3*/
insert into t_normal select * from temp_t;/*Q4*/

如果关于临时表的操作都不记录，那么在备库就只有create table t_normal表和insert into t_normal select * from temp_t这两个语句的binlog日志，备库在执行到insert into t_normal的时候，就会报错“表temp_t不存在”。

注意：

只在binlog_format=statment/mixed 的时候，binlog中才会记录临时表的操作。
对于binlog_format=row时，跟临时表有关的语句，就不会记录到binlog里。这种情况下，创建临时表的语句会传到备库执行，因此备库的同步线程就会创建这个临时表。主库在线程退出的时候，会自动删除临时表，但是备库同步线程是持续在运行的。所以，这时候就需要在主库上再写一个DROP TEMPORARY TABLE;传给备库执行。

7、主库上不同的线程创建同名的临时表传到备库执行是怎么处理的呢？

假设列中实例S是M的备库。

主库M上的两个session创建了同名的临时表t1，这两个create temporary table t1 语句都会被传到备库S上。但是备库的应用日志线程是共用的，也就是说要在应用线程里面先后执行这个create 语句两次。（即使开了多线程复制，也可能被分配到从库的同一个worker中执行）。那么，这会不会导致同步线程报错？
MySQL在记录binlog的时候，会把主库执行这个语句的线程id写到binlog中。这样，在备库的应用线程就能够知道执行每个语句的主库线程id，并利用这个线程id来构造临时表的table_def_key：

session A的临时表t1，在备库的table_def_key就是：库名+t1+“M的serverid”+“session A的thread_id”;
session B的临时表t1，在备库的table_def_key就是：库名+t1+“M的serverid”+“session B的thread_id”。
由于table_def_key不同，所以这两个表在备库的应用线程里面是不会冲突的。

MySQL实战45讲Day35----临时表可以重名的原因