问题：

MySQL 在处理临时结果集（UNION 运算 / 聚合运算等）时，会用到内部临时表（internal temporary table）。

那么内部临时表会使用多少内存呢？

实验：

我们先创建一个测试用的数据库，

然后准备好数据，

我们使用一个带 UNION 的子表，使执行计划会使用内部临时表：

可以看到执行计划确实使用了临时表：

下面我们另起一个 session，用 performance_schema 对内存进行观察：

在主 session 中，探查其连接号，并找到线程号：

在 performance_schema 中，确认其内存分配的统计初始状态：

在主 session 中执行 SQL：

在 performance_schema 中，查看其内存分配：

可知在这个 SQL 的处理过程中，总共分配了 4M 多的内存用于内部临时表：

我们都知道内存临时表是 memory(heap) 引擎格式的表，那我们手工建一个显式的内存表，应当和内存临时表使用的内存相同，来试验一下。

在主 session 中创建一张内存表，将数据插入到内存表中：

观察 performance_schema 可知：内存表驻留在内存里的字节数与之前临时表使用的字节数相同。

结论

我们通过 performance_schema 观察了 memory 引擎的内存分配，由此推算了内部临时表的内存占用情况。

MySQL 在其他元数据中，诸如 information_schema.INNODB_TEMP_TABLE_INFO 中，并不展示内部临时表的信息，如图：

另外值得注意的是：memory 引擎会多划分出不少空间，比如本例中我们的数据是 300025 行 * 4 字节 =~ 1.2M，而引擎分出了 4M 多的内存来进行存储。

因此如果进行估算时，需要将数据量乘以一个较大的系数，才能准确估算。

我们是第二次用到了 dbdeployer，介绍一下其身世：

dbdeployer 的前身是著名的 mysql-sandbox，是著名博主 Giuseppe Maxia 的扛鼎之作（http://datacharmer.blogspot.com），可以极其方便地搭建 MySQL 多种架构的测试环境，命令简单优雅。

今后在实验中，我们会多次用到 dbdeployer，或者使用 MySQL 容器进行快速搭建和试验。