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 容器进行快速搭建和试验。
关于 MySQL 的技术内容,你们还有什么想知道的吗?赶紧留言告诉小编吧!