展開全部

我們?nèi)允褂?實(shí)驗(yàn) 05?中的環(huán)境，略去準(zhǔn)備數(shù)據(jù)的過程。

我們?nèi)匀皇褂脙蓚€(gè)會(huì)話，62616964757a686964616fe59b9ee7ad9431333433646439一個(gè)會(huì)話 run，用于運(yùn)行主 SQL；另一個(gè)會(huì)話 ps，用于進(jìn)行 performance_schema 的觀察：

主會(huì)話線程號(hào)為 29，

將 performance_schema 中的統(tǒng)計(jì)量重置，

臨時(shí)表的表大小限制取決于參數(shù)? tmp_table_size 和 max_heap_table_size 中較小者，我們實(shí)驗(yàn)中以設(shè)置 max_heap_table_size 為例。

我們將會(huì)話級(jí)別的臨時(shí)表大小設(shè)置為 2M(小于上次實(shí)驗(yàn)中臨時(shí)表使用的空間)，執(zhí)行使用臨時(shí)表的 SQL：

查看內(nèi)存的分配記錄：

會(huì)發(fā)現(xiàn)內(nèi)存分配略大于 2M，我們猜測(cè)臨時(shí)表會(huì)比配置略多一點(diǎn)消耗，可以忽略。

查看語句的特征值：

可以看到語句使用了一次需要落磁盤的臨時(shí)表。

那么這張臨時(shí)表用了多少的磁盤呢？

我們開啟 performance_schema 中 waits 相關(guān)的統(tǒng)計(jì)項(xiàng)：

重做實(shí)驗(yàn)，略過。

再查看 performance_schema 的統(tǒng)計(jì)值：

可以看到幾個(gè)現(xiàn)象：

1. 臨時(shí)表空間被寫入了 7.92MiB 的數(shù)據(jù)。

2. 這些數(shù)據(jù)是語句寫入后，慢慢逐漸寫入的。

來看看這些寫入操作的特征，該方法我們?cè)?實(shí)驗(yàn) 03?使用過：

可以看到寫入的線程是 page_clean_thread，是一個(gè)刷臟操作，這樣就能理解數(shù)據(jù)為什么是慢慢寫入的。

也可以看到每個(gè) IO 操作的大小是 16K，也就是刷數(shù)據(jù)頁的操作。

結(jié)論：

我們可以看到，

1. MySQL 會(huì)基本遵守 max_heap_table_size 的設(shè)定，在內(nèi)存不夠用時(shí)，直接將表轉(zhuǎn)到磁盤上存儲(chǔ)。

2. 由于引擎不同(內(nèi)存中表引擎為 heap，磁盤中表引擎則跟隨 internal_tmp_disk_storage_engine 的配置)，本次實(shí)驗(yàn)寫磁盤的數(shù)據(jù)量和?實(shí)驗(yàn) 05?中使用內(nèi)存的數(shù)據(jù)量不同。

3. 如果臨時(shí)表要使用磁盤，表引擎配置為 InnoDB，那么即使臨時(shí)表在一個(gè)時(shí)間很短的 SQL 中使用，且使用后即釋放，釋放后也會(huì)刷臟頁到磁盤中，消耗部分 IO。

總結(jié)

以上是生活随笔為你收集整理的mysql临时表 清空_在数据库中临时表什么时候会被清除呢的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。