MySQL 5.7 内部临时表

本文研究了在没有写查询的情况下，InnoDB行插入时，因内部临时表的问题而发生性能尖刺的情形。

In this blog post, I investigate a case of spiking InnoDB Rows inserted in the absence of a write query, and find internal temporary tables to be the culprit.

事情发生在我研究一个客户的案例时，在”InnoDB行插入“指标图上，发现了从1k行每秒激增到6K行的尖刺，但却无法和其他活动或者现象连接起来，PMM监控图形上也有同样的反映。

Recently I was investigating an interesting case for a customer. We could see the regular spikes on a graph depicting “InnoDB rows inserted” metric (jumping from 1K/sec to 6K/sec), however we were not able to correlate those spikes with other activity. The innodb_row_inserted graph (picture fromPMM demo) looked similar to this (but on a much larger scale):

其他例如句柄和接口的图形都没有显示同样的尖刺，在无法开启general log的情况下，我们尝试检查了所有的日志，performance_schema，触发器，存储过程，预编译语句，甚至包括binlog后发现没有任何单个的写查询语句可以导致每秒插入飙升到6K行。

Other graphs (Com*, Handler) did not show any spikes like that. I’ve examined the logs (we were not able to enable general log or change the threshold of the slow log), performance_schema, triggers, stored procedures, prepared statements and even reviewed the binary logs. However, I was not able to find any single **\write*query which could have caused the spike to 6K rows inserted.

在最后才发现，行插入飙升一定和DML有关的这种想法是错误的，出乎意料的是，尖刺是由于SELECT查询导致的，但为何SELECT查询会导致大量的InnoDB行插入操作呢？

Finally, I figured out that I was focusing on the wrong queries. I was trying to correlate the spikes on the InnoDB Rows inserted graph to the DML queries (writes). However, the spike was caused by SELECT queries! But why would SELECT queries cause the massive InnoDB insert operation? How is this even possible?

原来是与磁盘临时表有关。在MySQL 5.7版本中，内部磁盘临时表的默认引擎是InnoDB引擎，这就意味着当SELECT操作需要在磁盘上创建临时表时（例如GROUP BY操作），就会使用到InnoDB引擎。

It turned out that this is related to temporary tables on disk. In MySQL 5.7 the default setting forinternal_tmp_disk_storage_engineis set for InnoDB. That means that if the SELECT needs to create a temporary table on disk (e.g., for GROUP BY) it will use the InnoDB storage engine.

但这种尖刺就一定意味着性能的下降吗？Krunal Bauskar曾经写过一篇关于5.7 InnoDB原生表性能的文章,InnoDB的内部临时表的操作并不会记录在redo和undo中，一般情况下相比原本MyISAM引擎的临时表性能更好点，但是仍需注意一下几点：

Is that bad? Not necessarily. Krunal Bauskar published a blog post originally about theInnoDB Intrinsic Tables performancein MySQL 5.7. The InnoDB internal temporary tables are not redo/undo logged. So in general performance is better. However, here is what we need to watch out for:

1、更改MySQL存储临时表的位置mssql 临时表，原本InnoDB临时表被存储在ibtmp1表空间中，可能遇到以下的问题：

Change of the place where MySQL stores temporary tables. InnoDB temporary tables are stored in ibtmp1 tablespace file. There are a number of challenges with that:

Conclusion 结论

内部InnoDB临时表（可能仅仅因为是SELECT查询导致）被保存在InnoDB的ibtmp文件中，在大部分情况下，会加速临时表或者查询的速度，但是会影响到原本InnoDB内存的占用情况和原本临时表处理的逻辑，如果在某种情况确实需要规避的话，可以尝试将临时表的引擎改回MyISAM：

set global internal_tmp_disk_storage_engine=MYISAM

Beware of the new change in MySQL 5.7, the internal temporary tables (those that are created for selects when a temporary table is needed) are stored in InnoDB ibtmp file. In most cases this is faster. However, it can change the original behavior. If needed, you can switch the creation of internal temp tables back to MyISAM: set globalinternal_tmp_disk_storage_engine=MYISAM.

这个案例要求我们要对MySQL 5.7的特性要有所注意和了解。

扫码加入知数堂技术交流QQ群

（群号：579036588）

（编辑：广州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!