MySQL实战45讲学习笔记：第三十六讲

1、引子

今天是大年三十，在开始咱们今天的学习以前，我要先和你道一声春节快乐！

在上一篇文章中，咱们在优化 join 查询的时候使用到了临时表。当时，咱们是这么用的：

create temporary table temp_t like t1;
alter table temp_t add index(b);
insert into temp_t select * from t2 where b>=1 and b<=2000;
select * from t1 join temp_t on (t1.b=temp_t.b);

你可能会有疑问，为何要用临时表呢？直接用普通表是否是也能够呢？

今天咱们就从这个问题提及：临时表有哪些特征，为何它适合这个场景？

这里，我须要先帮你厘清一个容易误解的问题：有的人可能会认为，临时表就是内存表。可是，这两个概念但是彻底不一样的。

内存表，指的是使用 Memory 引擎的表，建表语法是 create table …engine=memory。这种表的数据都保存在内存里，系统重启的时候会被清空，可是表
结构还在。除了这两个特性看上去比较“奇怪”外，从其余的特征上看，它就是一个正常的表。

而临时表，可使用各类引擎类型 。若是是使用 InnoDB 引擎或者 MyISAM 引擎的临时表，写数据的时候是写到磁盘上的。固然，临时表也可使用 Memory 引擎

弄清楚了内存表和临时表的区别之后，咱们再来看看临时表有哪些特征。

弄清楚了内存表和临时表的区别之后，咱们再来看看临时表有哪些特征。

2、临时表的特性

为了便于理解，咱们来看下下面这个操做序列：

图 1 临时表特性示例

能够看到，临时表在使用上有如下几个特色：

1. 建表语法是 create temporary table …。
2. 一个临时表只能被建立它的 session 访问，对其余线程不可见。因此，图中 session A建立的临时表 t，对于 session B 就是不可见的。
3. 临时表能够与普通表同名。
4. session A 内有同名的临时表和普通表的时候，show create 语句，以及增删改查语句访问的是临时表。
5. show tables 命令不显示临时表。

因为临时表只能被建立它的 session 访问，因此在这个 session 结束的时候，会自动删除临时表。也正是因为这个特性，临时表就特别适合咱们文章开头的 join 优化这种场景。为
什么呢？

缘由主要包括如下两个方面：

1. 不一样 session 的临时表是能够重名的，若是有多个 session 同时执行 join 优化，不须要担忧表名重复致使建表失败的问题。
2. 不须要担忧数据删除问题。若是使用普通表，在流程执行过程当中客户端发生了异常断开，或者数据库发生异常重启，还须要专门来清理中间过程当中生成的数据表。而临时表因为会自动回收，因此不须要这个额外的操做。

3、临时表的应用

一、分库分表简图

因为不用担忧线程之间的重名冲突，临时表常常会被用在复杂查询的优化过程当中。其中，分库分表系统的跨库查询就是一个典型的使用场景。

通常分库分表的场景，就是要把一个逻辑上的大表分散到不一样的数据库实例上。好比。将一个大表 ht，按照字段 f，拆分红 1024 个分表，而后分布到 32 个数据库实例上。

以下图所示：

图 2 分库分表简图

通常状况下，这种分库分表系统都有一个中间层 proxy。不过，也有一些方案会让客户端直接链接数据库，也就是没有 proxy 这一层。

在这个架构中，分区 key 的选择是以“减小跨库和跨表查询”为依据的。若是大部分的语句都会包含 f 的等值条件，那么就要用 f 作分区键。这样，在 proxy 这一层解析完 SQL
语句之后，就能肯定将这条语句路由到哪一个分表作查询。

好比下面这条语句：

select v from ht where f=N;

这时，咱们就能够经过分表规则（好比，N%1024) 来确认须要的数据被放在了哪一个分表上。这种语句只须要访问一个分表，是分库分表方案最欢迎的语句形式了。

可是，若是这个表上还有另一个索引 k，而且查询语句是这样的：

select v from ht where k >= M order by t_modified desc limit 100;

这时候，因为查询条件里面没有用到分区字段 f，只能到全部的分区中去查找知足条件的全部行，而后统一作 order by 的操做。这种状况下，有两种比较经常使用的思路。

二、第一种思路是，在 proxy 层的进程代码中实现排序。

第一种思路是，在 proxy 层的进程代码中实现排序。

这种方式的优点是处理速度快，拿到分库的数据之后，直接在内存中参与计算。不过，这个方案的缺点也比较明显：

1. 须要的开发工做量比较大。咱们举例的这条语句还算是比较简单的，若是涉及到复杂的操做，好比 group by，甚至 join 这样的操做，对中间层的开发能力要求比较高；
2. 对 proxy 端的压力比较大，尤为是很容易出现内存不够用和 CPU 瓶颈的问题。

三、另外一种思路就是，把各个分库拿到的数据，汇总到一个 MySQL 实例的一个表中，而后在这个汇总实例上作逻辑操做。

另外一种思路就是，把各个分库拿到的数据，汇总到一个 MySQL 实例的一个表中，而后在这个汇总实例上作逻辑操做。

好比上面这条语句，执行流程能够相似这样：

 select v from ht where k >= M order by t_modified desc limit 100;

在汇总库上建立一个临时表 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; 

获得结果。

这个过程对应的流程图以下所示：

图 3 跨库查询流程示意图

在实践中，咱们每每会发现每一个分库的计算量都不饱和，因此会直接把临时表 temp_ht放到 32 个分库中的某一个上。这时的查询逻辑与图 3 相似，你能够本身再思考一下具体的流程。

4、为何临时表能够重名？

一、不一样线程能够建立同名的临时表，这是怎么作到的呢？

你可能会问，不一样线程能够建立同名的临时表，这是怎么作到的呢？

接下来，咱们就看一下这个问题。

咱们在执行

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 的。

二、不一样线程能够建立同名的临时表验证过程

为了便于后面讨论，我先来举一个例子。

图 4 临时表的表名

这个进程的进程号是 1234，session A 的线程 id 是 4，session B 的线程 id 是 5。因此你看到了，session A 和 session B 建立的临时表，在磁盘上的文件不会重名。

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

• 一个普通表的 table_def_key 的值是由“库名 + 表名”获得的，因此若是你要在同一个库下建立两个同名的普通表，建立第二个表的过程当中就会发现 table_def_key 已经存在了。
• 而对于临时表，table_def_key 在“库名 + 表名”基础上，又加入了“server_id+thread_id”。

也就是说，session A 和 sessionB 建立的两个临时表 t1，它们的 table_def_key 不一样，磁盘文件名也不一样，所以能够并存。

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

这时候你会发现，binlog 中也记录了 DROP TEMPORARY TABLE 这条命令。你必定会以为奇怪，临时表只在线程内本身能够访问，为何须要写到 binlog 里面？

这，就须要说到主备复制了。

5、临时表和主备复制

一、若是关于临时表的操做都不记录、备库在执行到 insertinto t_normal 的时候，就会报错“表 temp_t 不存在”

既然写 binlog，就意味着备库须要。

你能够设想一下，在主库上执行下面这个语句序列：

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 表和 insertinto t_normal select * from temp_t 这两个语句的 binlog 日志，备库在执行到 insert
的时候，就会报错“表 temp_t 不存在”。

你可能会说，若是把 binlog 设置为 row 格式就行了吧？由于 binlog 是 row 格式时，在记录 insert into t_normal 的 binlog 时，记录的是这个操做的数据，即：write_rowevent
 里面记录的逻辑是“插入一行数据（1,1)”。

二、若是把 binlog 设置为 row 格式就行了吧？

确实是这样。若是当前的 binlog_format=row，那么跟临时表有关的语句，就不会记录到binlog 里。也就是说，只在 binlog_format=statment/mixed 的时候，binlog 中才会记
录临时表的操做。

这种状况下，建立临时表的语句会传到备库执行，所以备库的同步线程就会建立这个临时表。主库在线程退出的时候，会自动删除临时表，可是备库同步线程是持续在运行的。所
以，这时候咱们就须要在主库上再写一个 DROP TEMPORARY TABLE 传给备库执行。

三、MySQL 在记录 binlog 的时候drop tablet_normal改为了标准的格式。为何要这么作呢 ？

以前有人问过我一个有趣的问题：MySQL 在记录 binlog 的时候，不管是 create table仍是 alter table 语句，都是原样记录，甚至于连空格都不变。可是若是执行 drop tablet_normal，
系统记录 binlog 就会写成：

DROP TABLE `t_normal` /* generated by server */

也就是改为了标准的格式。为何要这么作呢 ？

如今你知道缘由了，那就是：drop table 命令是能够一次删除多个表的。好比，在上面的例子中，设置 binlog_format=row，若是主库上执行 "drop table t_normal, temp_t"这个命令，那么 binlog 中就只能记录：

DROP TABLE `t_normal` /* generated by server */

由于备库上并无表 temp_t，将这个命令重写后再传到备库执行，才不会致使备库同步线程中止。

因此，drop table 命令记录 binlog 的时候，就必须对语句作改写。“/* generated byserver */”说明了这是一个被服务端改写过的命令。

四、主库上不一样的线程建立同名的临时表是不要紧的，可是传到备库执行是怎么处理的呢？

说到主备复制，还有另一个问题须要解决：主库上不一样的线程建立同名的临时表是不要紧的，可是传到备库执行是怎么处理的呢？

如今，我给你举个例子，下面的序列中实例 S 是 M 的备库。

图 5 主备关系中的临时表操做

主库 M 上的两个 session 建立了同名的临时表 t1，这两个 create temporary table t1语句都会被传到备库 S 上。

可是，备库的应用日志线程是共用的，也就是说要在应用线程里面前后执行这个 create 语句两次。（即便开了多线程复制，也可能被分配到从库的同一个 worker 中执行）。那
么，这会不会致使同步线程报错 ？

显然是不会的，不然临时表就是一个 bug 了。也就是说，备库线程在执行的时候，要把这两个 t1 表当作两个不一样的临时表来处理。这，又是怎么实现的呢？

MySQL 在记录 binlog 的时候，会把主库执行这个语句的线程 id 写到 binlog 中。这样，在备库的应用线程就可以知道执行每一个语句的主库线程 id，并利用这个线程 id 来构
造临时表的 table_def_key：

1. session A 的临时表 t1，在备库的 table_def_key 就是：库名 +t1+“M 的serverid”+“session A 的 thread_id”;
2. session B 的临时表 t1，在备库的 table_def_key 就是 ：库名 +t1+“M 的serverid”+“session B 的 thread_id”。

因为 table_def_key 不一样，因此这两个表在备库的应用线程里面是不会冲突的。

6、小结

今天这篇文章，我和你介绍了临时表的用法和特性。

在实际应用中，临时表通常用于处理比较复杂的计算逻辑。因为临时表是每一个线程本身可见的，因此不须要考虑多个线程执行同一个处理逻辑时，临时表的重名问题。在线程退出
的时候，临时表也能自动删除，省去了收尾和异常处理的工做。

在 binlog_format='row’的时候，临时表的操做不记录到 binlog 中，也省去了很多麻烦，这也能够成为你选择 binlog_format 时的一个考虑因素。

须要注意的是，咱们上面说到的这种临时表，是用户本身建立的 ，也能够称为用户临时表。与它相对应的，就是内部临时表，在第 17 篇文章中我已经和你介绍过。

最后，我给你留下一个思考题吧。

下面的语句序列是建立一个临时表，并将其更名：

图 6 关于临时表更名的思考题

能够看到，咱们可使用 alter table 语法修改临时表的表名，而不能使用 rename 语法。你知道这是什么缘由吗？

你能够把你的分析写在留言区，我会在下一篇文章的末尾和你讨论这个问题。感谢你的收听，也欢迎你把这篇文章分享给更多的朋友一块儿阅读。

7、上期问题时间

上期的问题是，对于下面这个三个表的 join 语句，

select * from t1 join t2 on(t1.a=t2.a) join t3 on (t2.b=t3.b) where t1.c>=X and t2.c>=Y and t3.c>=Z;

若是改写成 straight_join，要怎么指定链接顺序，以及怎么给三个表建立索引。

第一原则是要尽可能使用 BKA 算法。须要注意的是，使用 BKA 算法的时候，并非“先计算两个表 join 的结果，再跟第三个表 join”，而是直接嵌套查询的。

具体实现是：在 t1.c>=X、t2.c>=Y、t3.c>=Z 这三个条件里，选择一个通过过滤之后，数据最少的那个表，做为第一个驱动表。此时，可能会出现以下两种状况。

第一种状况，若是选出来是表 t1 或者 t3，那剩下的部分就固定了。

1. 若是驱动表是 t1，则链接顺序是 t1->t2->t3，要在被驱动表字段建立上索引，也就是t2.a 和 t3.b 上建立索引；

2. 若是驱动表是 t3，则链接顺序是 t3->t2->t1，须要在 t2.b 和 t1.a 上建立索引。同时，咱们还须要在第一个驱动表的字段 c 上建立索引。

第二种状况是，若是选出来的第一个驱动表是表 t2 的话，则须要评估另外两个条件的过滤效果。

总之，总体的思路就是，尽可能让每一次参与 join 的驱动表的数据集，越小越好，由于这样咱们的驱动表就会越小。

评论区留言点赞板：

@库淘淘 作了实验验证；@poppy 同窗作了很不错的分析；@dzkk 同窗在评论中介绍了 MariaDB 支持的 hash join，你们能够了解一下；@老杨同志提了一个好问题，若是语句使用了索引 a，结果还要对 a 排序，就不用 MRR 优化了，不然回表完还要增长额外的排序过程，得不偿失。