产品中心
今天我们就从这个问题说起：临时表有哪些特征，适合哪些场景？
这里，我需要先帮你厘清一个容易误解的问题：有的人可能会认为，临时表就是内存表。但是，这两个概念可是完全不同的。
弄清楚了内存表和临时表的区别以后，我们再来看看临时表有哪些特征。
为了便于理解，我们来看下下面这个操作序列：
可以看到，临时表在使用上有以下几个特点：
由于临时表只能被创建它的session访问，所以在这个session结束的时候，会自动删除临时表。
也正是由于这个特性，临时表就特别适合上篇文章中join优化这种场景。为什么呢？ 原因主要包括以下两个方面：
由于不用担心线程之间的重名冲突，临时表经常会被用在复杂查询的优化过程中。其中，分库分表系统的跨库查询就是一个典型的使用场景。
一般分库分表的场景，就是要把一个逻辑上的大表分散到不同的数据库实例上。比如。将一个大表ht，按照字段f，拆分成1024个分表，然后分布到32个数据库实例上。如下图所示：
一般情况下，这种分库分表系统都有一个中间层proxy。不过，也有一些方案会让客户端直接连接数据库，也就是没有proxy这一层。
在这个架构中，分区key的选择是以“减少跨库和跨表查询”为依据的。如果大部分的语句都会包含f的等值条件，那么就要用f做分区键。这样，在proxy这一层解析完SQL语句以后，就能确定将这条语句路由到哪个分表做查询。
比如下面这条语句：
在实践中，我们往往会发现每个分库的计算量都不饱和，所以会直接把临时表temp_ht放到32个分库中的某一个上。
你可能会问，不同线程可以创建同名的临时表，这是怎么做到的呢？
我们在执行
这个进程的进程号是1234，session A的线程id是4，session B的线程id是5。所以你看到了，session A和session B创建的临时表，在磁盘上的文件不会重名。
MySQL维护数据表，除了物理上要有文件外，内存里面也有一套机制区别不同的表，每个表都对应一个table_def_key。
也就是说，session A和session B创建的两个临时表t1，它们的table_def_key不同，磁盘文件名也不同，因此可以并存。
在实现上，每个线程都维护了自己的临时表链表。这样每次session内操作表的时候，先遍历链表，检查是否有这个名字的临时表，如果有就优先操作临时表，如果没有再操作普通表；在session结束的时候，对链表里的每个临时表，执行 “DROPTEMPORARY TABLE +表名”操作。
这时候你会发现，binlog中也记录了DROPTEMPORARY TABLE这条命令。你一定会觉得奇怪，临时表只在线程内自己可以访问，为什么需要写到binlog里面？这，就需要说到主备复制了。
既然写binlog，就意味着备库需要。 你可以设想一下，在主库上执行下面这个语句序列：
主库M上的两个session创建了同名的临时表t1，这两个create temporary table t1 语句都会被传到备库S上。
但是，备库的应用日志线程是共用的，也就是说要在应用线程里面先后执行这个create 语句两次。（即使开了多线程复制，也可能被分配到从库的同一个worker中执行）。那么，这会不会导致同步线程报错？
显然是不会的，否则临时表就是一个bug了。也就是说，备库线程在执行的时候，要把这两个t1表当做两个不同的临时表来处理。这，又是怎么实现的呢？ MySQL在记录binlog的时候，会把主库执行这个语句的线程id写到binlog中。这样，在备库的应用线程就能够知道执行每个语句的主库线程id，并利用这个线程id来构造临时表的table_def_key：
由于table_def_key不同，所以这两个表在备库的应用线程里面是不会冲突的。
到此这篇关于SQL开发知识：SQL开发知识：MySQL为什么临时表可以重名的文章就介绍到这了,更多相关MySQL临时表重名内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！
