临时表和SQL SELECT性能

Question

为什么使用带有SELECT语句的临时表可以改善逻辑I / O数量？ 它不会增加数据库的点击量而不是减少它。 这是因为'问题'被分解成了几个部分吗？ 我想知道幕后发生了什么。

Answer 1

没有一般的答案。 这取决于临时表的使用方式。

临时表可以通过缓存在批处理中多次使用的复杂过滤器/连接之后创建的行来减少IO。 这样，当只需要一部分记录时，DB可以避免多次命中基表。

临时表可以通过存储以后从未在查询中使用的记录来增加IO，或者通过占用引擎缓存中可能被其他数据更好地使用的大量空间来增加IO。

创建临时表以使用其所有内容一次比在主查询中包含temp的查询要慢，因为查询优化器无法看到临时表，并且它强制（可能）不必要的数据假脱机而不是允许它从源表流式传输。

Answer 2

我将假设临时表是指WHERE子句中的子选择。 （这被称为半连接操作，您通常可以在查询的文本执行计划中看到它。）

当查询优化器遇到子选择/临时表时，它会对如何处理该数据做出一些假设。 本质上，优化器将创建一个执行计划，该计划在子选择的结果集上执行连接，从而减少需要从其他表读取的行数。 由于行数较少，查询引擎能够从磁盘/内存中读取较少的页面并减少所需的I / O量。

Answer 3

AFAIK，至少使用mysql，tmp表保存在RAM中，使SELECT比任何撞击HD的速度快得多

Answer 4

有一类问题，在数据库端的集合结构中构建结果比将结果的部分返回给客户端更为可取，每个部分都需要进行往返。

例如：任意深度递归关系（boss）

还有另一类查询问题，其中数据不会也不会以使查询高效运行的方式编制索引。 将结果拉入可以自定义方式索引的集合结构将减少这些查询的逻辑IO。