数据库中使用临时表有好处也有坏处，那么它会有哪些问题呢？这在面试中也会被经常问到，今天咱就结合实际案例，好好唠唠数据库中使用临时表可能带来的一系列问题，希望能给各位正在搬砖的程序员小伙伴们提个醒。

一、一场由临时表引发的“性能危机”

前段时间，我在处理一个性能问题时，发现“罪魁祸首”竟然是临时表。有个小伙伴在处理内存数据时用到了临时表，一开始数据量少，系统运行得还算顺畅，没暴露出啥问题。可随着业务发展，数据量逐渐增大，线上好几家租户都反馈说系统响应变得特别慢，打开页面要等好久，甚至一些API还出现了超时的情况。经过好几轮排查分析，最终确定问题就出在这临时表上。

当时小伙伴使用临时表，主要是图方便。想着在临时表里能像在真实数据表那样进行聚合、关联、排序操作，这样就能少写不少业务代码，节省开发时间。出发点是好的，但没想到后面会引发这么大的麻烦。

二、临时表在数据量增大时的性能瓶颈

虽然在数据量较小的时候，临时表可以在内存中高效处理数据，索引也能正常发挥作用，用起来确实挺方便。但一旦数据量上来了，问题就接踵而至。

大家都知道，内存空间是有限的。数据量过大时，临时表无法把所有数据都存放在内存里。为了释放内存空间，索引可能会把部分数据写入磁盘。而磁盘的访问速度和内存相比，那可差远了。这就好比你原本在伸手就能拿到东西的地方存放物品，现在却要跑到老远的仓库去取，效率自然就大打折扣。数据量大时，查询临时表很容易导致全表扫描，查询速度慢得让人抓狂。

其实，要是想对内存中的数据进行聚合、关联计算，不一定要用临时表。就拿Java来说，Java 8及以后的版本支持lambda表达式，用它来处理这些计算，效率还是挺不错的，大家不妨试试。

三、临时表带来的额外存储和性能开销

除了数据量增大导致的性能问题，使用临时表还会占用存储空间，不管是内存还是磁盘都得“贡献”出空间给它。要是数据量比较大，创建和查询临时表的过程中，会频繁触发磁盘IO操作。这就像不停地在硬盘上读写文件，会严重影响查询性能。

要是API存在并发操作，情况就更糟糕了。频繁地创建和销毁临时表，会让系统资源在这上面消耗过多，引发更严重的性能问题。

四、临时表在分布式事务中的“水土不服”

还有个让人头疼的问题，就是临时表在分布式事务场景下基本“玩不转”。就拿Seata来说，它是常用的分布式事务解决方案，但Seata并不支持临时表。

临时表创建后会立刻插入数据，可Seata没办法及时获取到临时表的结构和元数据，也就无法生成反向的SQL语句。这就好比你做了一件事，却没有留下“反悔”的余地。一旦出现问题需要回滚数据，Seata根本没办法操作，管理器找不到临时表的元数据，还会直接报错说表不存在。所以在涉及分布式事务的场景里，一般都不建议使用临时表。

今天关于数据库中临时表使用问题的分享就到这儿啦！要是大家在实际开发中对临时表还有其他疑问，或者也遇到过类似的问题，欢迎在评论区留言交流！