深入理解MySQL中的临时表

说实话，当我第一次接触MySQL临时表时，我把它和永久表混淆了。
记得当时在一个电商项目中，有一个报表查询速度特别慢。
数据库管理员（DBA）检查后发现排序操作减慢了整个查询的速度。
当时他在SQL中直接使用ORDER BY，但是结果数据量大的时候数据就卡住了。
后来我改变主意，把需要排序的字段丢到临时表里，顺便建个索引，然后从临时表里排序。
嘿，你猜怎么着？查询速度直接快了至少三个数量级。
这是临时表的第一个能力——排序优化，我印象特别深刻。

有趣的是临时表的分类。
起初我不记得本地临时表和全局临时表之间的区别。
我写了一个存储过程后，想复用过程中的数据，于是就想到创建一个临时表来存储中间结果。
结果，创建了一个带有前缀的临时全局表，我发现外部会话也可以看到这个表，这让我很困惑。
后来DBA告诉我，临时本地服务台就像你租的房子，你住的时候可以使用，但你走的时候主人会把它移走，其他人不能进入；全局临时表更像是一个公共社区活动室，任何人都可以使用，但要注意不要冲突。
这个比喻其实非常贴切。

说到使用场景，深度查询优化绝对是一大亮点。
之前做过一个金融行业的项目，控制一个客户的交易流程，包括三层嵌套JOIN。
直接写SQL，客户端会苦苦等待。
后来技术负责人执行了一个临时表来存储一级JOIN结果，然后根据这个临时表进行二级JOIN，最后对原表进行JOIN。
整个查询时间直接从几分钟下降到十几秒。
当时我和经理讨论是否将所有复杂查询转换为临时表，但他提醒我，临时表虽然快，但维护成本也很高。
说白了，它是一个加速器，而不是一个总开关。

很少有人真正知道如何使用链接数据共享。
我遇到了批量迁移问题。
新旧集群之间的数据同步尤其麻烦，而且新集群的查询逻辑与旧集群并不完全相同。
最后，我们使用全局临时表在旧集群中生成中间数据，然后将其传递到新集群进行查询。
虽然我最终发现有一个更优雅的解决方案，但我当时认为这个想法非常酷。
当然，使用这种方法时必须非常注意数据的一致性。
我见过有人侥幸逃脱惩罚，并且数据在很长一段时间内都被搞乱了。

创建和使用表格临时其实很简单。
我手头有一个测试脚本，经常使用CREATE TEMPORARY TABLES来快速生成测试数据集。
比如我最近在测试一个分库分表的逻辑。
临时表比视图方便得多。
您还可以使用 INSERT 和 DELETE 直接访问数据，而不必每次都编写视图逻辑。
但请注意，临时表的生命周期与您的数据库会话相关。
我曾经写过一个脚本，运行了很长时间，但是中间出了问题，临时表没有了。
前半天的工作白费了。
我当时真的很生气。

最后要注意的是。
临时表确实可以提高性能，但如果使用不当也会带来问题。
例如，在高耦合场景下，我发现当多个会话使用本地临时表时，虽然互不干扰，但数据库的临时目录已经快满了。
还有临时全局表。
虽然它们可以在服务器级别共享，但是当服务器重新启动时所有数据都会丢失，因此它们不适合存储重要数据。
我建议初学者先从本地临时表开始练习，熟练后再考虑全局临时表。
这个顺序实际上对于避免陷入麻烦非常重要。

MySQL临时表的用法和创建方式mysql临时表

创建本地临时表： 创建表 temp_table(id INT, name VARCHAR(5 0));
创建全局临时表： 创建表 temp_table(id INT, name VARCHAR(5 0));
使用场景： 1 、数据处理不影响底层数据。
2 、多个查询共享数据，提高性能（例如：2 02 2 年，某电商系统使用临时表，将报表生成速度提高了3 0%）。

注意：它会在会话结束时自动删除。

实用提醒： 创建一个直接以 或 开头的临时表。