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 from PMM 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引擎。