這篇文章給大家分享的是有關(guān)MySQL學(xué)習(xí)之臨時(shí)表是什么的內(nèi)容。小編覺(jué)得挺實(shí)用的，因此分享給大家做個(gè)參考。一起跟隨小編過(guò)來(lái)看看吧。
創(chuàng)新互聯(lián)基于成都重慶香港及美國(guó)等地區(qū)分布式IDC機(jī)房數(shù)據(jù)中心構(gòu)建的電信大帶寬，聯(lián)通大帶寬，移動(dòng)大帶寬，多線BGP大帶寬租用,是為眾多客戶(hù)提供專(zhuān)業(yè)服務(wù)器托管報(bào)價(jià)，主機(jī)托管價(jià)格性?xún)r(jià)比高，為金融證券行業(yè)成都聯(lián)通服務(wù)器托管，ai人工智能服務(wù)器托管提供bgp線路100M獨(dú)享，G口帶寬及機(jī)柜租用的專(zhuān)業(yè)成都idc公司。
臨時(shí)表可以分為磁盤(pán)臨時(shí)表和內(nèi)存臨時(shí)表，而臨時(shí)文件，只會(huì)存在于磁盤(pán)上，不會(huì)存在于內(nèi)存中。具體來(lái)說(shuō)，臨時(shí)表的內(nèi)存形態(tài)有Memory引擎和Temptable引擎，主要區(qū)別是對(duì)字符類(lèi)型(varchar, blob，text類(lèi)型)的存儲(chǔ)方式，前者不管實(shí)際字符多少，都是用定長(zhǎng)的空間存儲(chǔ)，后者會(huì)用變長(zhǎng)的空間存儲(chǔ)，這樣提高了內(nèi)存中的存儲(chǔ)效率，有更多的數(shù)據(jù)可以放在內(nèi)存中處理而不是轉(zhuǎn)換成磁盤(pán)臨時(shí)表。Memory引擎從早期的5.6就可以使用，Temptable是8.0引入的新的引擎。另外一方面，磁盤(pán)臨時(shí)表也有三種形態(tài)，一種是MyISAM表，一種是InnoDB臨時(shí)表，另外一種是Temptable的文件map表。其中最后一種方式，是8.0提供的。
在5.6以及以前的版本，磁盤(pán)臨時(shí)表都是放在數(shù)據(jù)庫(kù)配置的臨時(shí)目錄，磁盤(pán)臨時(shí)表的undolog都是與普通表的undo放在一起(注意由于磁盤(pán)臨時(shí)表在數(shù)據(jù)庫(kù)重啟后就被刪除了，不需要redolog通過(guò)奔潰恢復(fù)來(lái)保證事務(wù)的完整性，所以不需要寫(xiě)redolog，但是undolog還是需要的，因?yàn)樾枰С只貪L)。
在MySQL 5.7后，磁盤(pán)臨時(shí)表的數(shù)據(jù)和undo都被獨(dú)立出來(lái)，放在一個(gè)單獨(dú)的表空間ibtmp1里面。之所以把臨時(shí)表獨(dú)立出來(lái)，主要是為了減少創(chuàng)建刪除表時(shí)維護(hù)元數(shù)據(jù)的開(kāi)銷(xiāo)。
在MySQL 8.0后，磁盤(pán)臨時(shí)表的數(shù)據(jù)單獨(dú)放在Session臨時(shí)表空間池(#innodb_temp目錄下的ibt文件)里面，臨時(shí)表的undo放在global的表空間ibtmp1里面。另外一個(gè)大的改進(jìn)是，8.0的磁盤(pán)臨時(shí)表數(shù)據(jù)占用的空間在連接斷開(kāi)后，就能釋放給操作系統(tǒng)，而5.7的版本中需要重啟才能釋放。
目前有以下兩種情況會(huì)用到臨時(shí)表：
這種是用戶(hù)通過(guò)顯式的執(zhí)行命令create temporary table創(chuàng)建的表，引擎的類(lèi)型要么顯式指定，要么使用默認(rèn)配置的值(default_tmp_storage_engine)。內(nèi)存使用就遵循指定引擎的內(nèi)存管理方式，比如InnoDB的表會(huì)先緩存在Buffer Pool中，然后通過(guò)刷臟線程寫(xiě)回磁盤(pán)文件。
在5.6中，磁盤(pán)臨時(shí)表位于tmpdir下，文件名類(lèi)似#sql4d2b_8_0.ibd，其中#sql是固定的前綴，4d2b是進(jìn)程號(hào)的十六進(jìn)制表示，8是MySQL線程號(hào)的十六進(jìn)制表示(show processlist中的id)，0是每個(gè)連接從0開(kāi)始的遞增值，ibd是innodb的磁盤(pán)臨時(shí)表(通過(guò)參數(shù)default_tmp_storage_engine控制)。在5.6中，磁盤(pán)臨時(shí)表創(chuàng)建好后，對(duì)應(yīng)的frm以及引擎文件就在tmpdir下創(chuàng)建完畢，可以通過(guò)文件系統(tǒng)ls命令查看到。在連接關(guān)閉后，相應(yīng)文件自動(dòng)刪除。因此，我們?nèi)绻?.6的tmpdir里面看到很多類(lèi)似格式文件名，可以通過(guò)文件名來(lái)判斷是哪個(gè)進(jìn)程，哪個(gè)連接使用的臨時(shí)表，這個(gè)技巧在排查tmpdir目錄占用過(guò)多空間的問(wèn)題時(shí)，尤其適用。用戶(hù)顯式創(chuàng)建的這種臨時(shí)表，在連接釋放的時(shí)候，會(huì)自動(dòng)釋放并把空間釋放回操作系統(tǒng)。臨時(shí)表的undolog存在undo表空間中，與普通表的undo放在一起。有了undo回滾段，用戶(hù)創(chuàng)建的這種臨時(shí)表也能支持回滾了。
在5.7中，臨時(shí)磁盤(pán)表位于ibtmp文件中，ibtmp文件位置及大小控制方式由參數(shù)innodb_temp_data_file_path控制。顯式創(chuàng)建的表的數(shù)據(jù)和undo都在ibtmp里面。用戶(hù)連接斷開(kāi)后，臨時(shí)表會(huì)釋放，但是僅僅是在ibtmp文件里面標(biāo)記一下，空間是不會(huì)釋放回操作系統(tǒng)的。如果要釋放空間，需要重啟數(shù)據(jù)庫(kù)。另外，需要注意的一點(diǎn)是，5.6可以在tmpdir下直接看到創(chuàng)建的文件，但是5.7是創(chuàng)建在ibtmp這個(gè)表空間里面，因此是看不到具體的表文件的。如果需要查看，則需要查看INFORMATION_SCHEMA.INNODB_TEMP_TABLE_INFO這個(gè)表，里面有一列name，這里可以看到表名。命名規(guī)格與5.6的類(lèi)似，因此也可以快速找到占用空間大的連接。
在8.0中，臨時(shí)表的數(shù)據(jù)和undo被進(jìn)一步分開(kāi)，數(shù)據(jù)是存放在ibt文件中(由參數(shù)innodb_temp_tablespaces_dir控制)，undo依然存放在ibtmp文件中(依然由參數(shù)innodb_temp_data_file_path控制)。存放ibt文件的叫做Session臨時(shí)表空間，存放undo的ibtmp叫做Global臨時(shí)表空間。這里介紹一下這個(gè)存放數(shù)據(jù)的Session臨時(shí)表空間。Session臨時(shí)表空間，在磁盤(pán)上的表現(xiàn)是一組以ibt文件組成的文件池。啟動(dòng)的時(shí)候，數(shù)據(jù)庫(kù)會(huì)在配置的目錄下重新創(chuàng)建，關(guān)閉數(shù)據(jù)庫(kù)的時(shí)候刪除。啟動(dòng)的時(shí)候，默認(rèn)會(huì)創(chuàng)建10個(gè)ibt文件，每個(gè)連接最多使用兩個(gè)，一個(gè)給用戶(hù)創(chuàng)建的臨時(shí)表用，另外一個(gè)給下文描述的優(yōu)化器創(chuàng)建的隱式臨時(shí)表使用。當(dāng)然只有在需要臨時(shí)表的時(shí)候，才會(huì)創(chuàng)建，如果不需要，則不會(huì)占用ibt文件。當(dāng)10個(gè)ibt都被使用完后，數(shù)據(jù)庫(kù)會(huì)繼續(xù)創(chuàng)建，最多創(chuàng)建四十萬(wàn)個(gè)。當(dāng)連接釋放時(shí)候，會(huì)自動(dòng)把這個(gè)連接使用的ibt文件給釋放，同時(shí)回收空間。如果要回收Global臨時(shí)表空間，依然需要重啟。但是由于已經(jīng)把存放數(shù)據(jù)的文件分離出來(lái)，且其支持動(dòng)態(tài)回收(即連接斷開(kāi)即釋放空間)，所以5.7上困擾大家多時(shí)的空間占用問(wèn)題，已經(jīng)得到了很好的緩解。當(dāng)然，還是有優(yōu)化空間的，例如，空間需要在連接斷開(kāi)后，才能釋放，而理論上，很多空間在某些SQL(如用戶(hù)drop了某個(gè)顯式創(chuàng)建的臨時(shí)表)執(zhí)行后，即可以釋放。另外，如果需要查看表名，依然查看INFORMATION_SCHEMA.INNODB_TEMP_TABLE_INFO這個(gè)表。需要注意的是，8.0上，顯式臨時(shí)表不能是壓縮表，而5.6和5.7可以。
這種臨時(shí)表，是數(shù)據(jù)庫(kù)為了輔助某些復(fù)雜SQL的執(zhí)行而創(chuàng)建的輔助表，是否需要臨時(shí)表，一般都是由優(yōu)化器決定。與用戶(hù)顯式創(chuàng)建的臨時(shí)表直接創(chuàng)建磁盤(pán)文件不同，如果需要優(yōu)化器覺(jué)得SQL需要臨時(shí)表輔助，會(huì)先使用內(nèi)存臨時(shí)表，如果超過(guò)配置的內(nèi)存(min(tmp_table_size, max_heap_table_siz))，就會(huì)轉(zhuǎn)化成磁盤(pán)臨時(shí)表，這種磁盤(pán)臨時(shí)表就類(lèi)似用戶(hù)顯式創(chuàng)建的，引擎類(lèi)型通過(guò)參數(shù)internal_tmp_disk_storage_engine控制。一般稍微復(fù)雜一點(diǎn)的查詢(xún)，包括且不限于order by, group by, distinct等，都會(huì)用到這種隱式創(chuàng)建的臨時(shí)表。用戶(hù)可以通過(guò)explain命令，在Extra列中，看是否有Using temporary這樣的字樣，如果有，就肯定要用臨時(shí)表。
在5.6中，隱式臨時(shí)表依然在tmpdir下，在復(fù)雜SQL執(zhí)行的過(guò)程中，就能看到這臨時(shí)表，一旦執(zhí)行結(jié)束，就被刪除。值得注意的是，5.6中，這種隱式創(chuàng)建的臨時(shí)表，只能用MyISAM引擎，即沒(méi)有internal_tmp_disk_storage_engine這個(gè)參數(shù)可以控制。所以，當(dāng)我們的系統(tǒng)中只有innodb表時(shí)，也會(huì)看到MyISAM的某些指標(biāo)在變動(dòng)，這種情況下，一般都是隱式臨時(shí)表的原因。
在5.7中，隱式臨時(shí)表是創(chuàng)建在ibtmp文件中的，SQL結(jié)束后，會(huì)標(biāo)記刪除，但是空間依然不會(huì)返還給操作系統(tǒng)，如果需要返還，則需要重啟數(shù)據(jù)庫(kù)。另外，5.7支持參數(shù)internal_tmp_disk_storage_engine，用戶(hù)可以選擇InnoDB或者M(jìn)YISAM表作為磁盤(pán)臨時(shí)表。
在8.0中，隱式臨時(shí)表是創(chuàng)建在Session臨時(shí)表空間中的，即與用戶(hù)顯式創(chuàng)建的臨時(shí)表的數(shù)據(jù)放在一起。如果一個(gè)連接第一次需要隱式臨時(shí)表，那么數(shù)據(jù)庫(kù)會(huì)從ibt文件構(gòu)成的池子中取出一個(gè)給這個(gè)連接使用，直到連接釋放。上文中，我們也提到過(guò)，在8.0中，用戶(hù)顯式創(chuàng)建的臨時(shí)表也會(huì)從池子中分配一個(gè)ibt來(lái)使用，每個(gè)連接最多使用兩個(gè)ibt文件用來(lái)存儲(chǔ)臨時(shí)表。我們可以查詢(xún)INFORMATION_SCHEMA.INNODB_SESSION_TEMP_TABLESPACES來(lái)確定ibt文件的去向。這個(gè)表中，每個(gè)ibt文件是一行，當(dāng)前系統(tǒng)中有幾個(gè)ibt文件就有幾行。有一列叫做ID，如果此列為0，表示此ibt沒(méi)有被使用，如果非0，表示被此ID的連接在用，比如ID為8，則表示process_id為8的連接在用這個(gè)ibt文件。另外，還有一列purpose，值為INTRINSIC表示是隱式臨時(shí)表在用這個(gè)ibt，USER則表示是顯示臨時(shí)表在用。此外，還有一列size，表示當(dāng)前的大小。用戶(hù)可以查詢(xún)這個(gè)表來(lái)確定整個(gè)數(shù)據(jù)庫(kù)臨時(shí)表的使用情況，十分方便。
在5.6和5.7中，內(nèi)存臨時(shí)表只能使用Memory引擎，到了8.0，多了一種Temptable引擎的選擇。Temptable在存儲(chǔ)格式有采用了變長(zhǎng)存儲(chǔ)，可以節(jié)省存儲(chǔ)空間，進(jìn)一步提高內(nèi)存使用率，減少轉(zhuǎn)換成磁盤(pán)臨時(shí)表的次數(shù)。如果設(shè)置的磁盤(pán)臨時(shí)表是InnoDB或者M(jìn)YISAM，則需要一個(gè)轉(zhuǎn)換拷貝的消耗。為了盡可能減少消耗，Temptable提出了一種overflow機(jī)制，即如果內(nèi)存臨時(shí)表超過(guò)配置大小，則使用磁盤(pán)空間map的方式，即打開(kāi)一個(gè)文件，然后刪除，留一個(gè)句柄進(jìn)行讀寫(xiě)操作。讀寫(xiě)文件格式和內(nèi)存中格式一樣，這樣就略過(guò)了轉(zhuǎn)換這一步，進(jìn)一步提高性能。注意，這個(gè)功能是在還沒(méi)發(fā)布的8.0.16版本中才有的，因?yàn)檫€看不到代碼，只能通過(guò)文檔猜測(cè)其實(shí)現(xiàn)。在8.0.16中，參數(shù)internal_tmp_disk_storage_engine已經(jīng)被去掉，磁盤(pán)臨時(shí)表只能使用InnoDB形式或者TempTable的這種overflow形式。從文檔中，我們似乎看出官方比較推薦使用TempTable這個(gè)新的引擎。具體性能提升情況，還需要等代碼發(fā)布后，測(cè)試過(guò)才能得出結(jié)論。
相比臨時(shí)表，臨時(shí)文件對(duì)大家可能更加陌生，臨時(shí)文件更多的被使用在緩存數(shù)據(jù)，排序數(shù)據(jù)的場(chǎng)景中。一般情況下，被緩存或者排序的數(shù)據(jù)，首先放在內(nèi)存中，如果內(nèi)存放不下，才會(huì)使用磁盤(pán)臨時(shí)文件的方式。臨時(shí)文件的使用方式與一般的表也不太一樣，一般的表創(chuàng)建完后，就開(kāi)始讀寫(xiě)數(shù)據(jù)，使用完后，才把文件刪除，但是臨時(shí)文件的使用方式不一樣，在創(chuàng)建完后(使用mkstemp系統(tǒng)函數(shù))，馬上調(diào)用unlink刪除文件，但是不close文件，后續(xù)使用原來(lái)的句柄操作文件。這樣的好處是，當(dāng)進(jìn)程異常crash，不會(huì)有臨時(shí)文件因?yàn)闆](méi)被刪除而殘留，但是壞處也是明顯的，我們?cè)谖募到y(tǒng)上使用ls命令就看不到這個(gè)文件，需要使用lsof +L1來(lái)查看這種deleted屬性的文件。
目前，我們主要在一下場(chǎng)景使用臨時(shí)文件：
在做online DDL的過(guò)程中，很多操作需要對(duì)原表進(jìn)行重建，對(duì)表重建前，需要對(duì)各種二級(jí)索引排序，而大量數(shù)據(jù)的排序，不太可能在內(nèi)存中完成，需要依賴(lài)外部排序算法，MySQL使用了歸并排序。這個(gè)過(guò)程中就需要?jiǎng)?chuàng)建臨時(shí)文件。一般需要的空間大小與原表差不多。但是在使用完之后，會(huì)馬上清理，所以在做DDL的時(shí)候，需要保留出足夠的空間。用戶(hù)可以通過(guò)指定innodb_tmpdir來(lái)指定這種排序文件的路徑。這個(gè)參數(shù)可以動(dòng)態(tài)修改，一般把他設(shè)置在有足夠磁盤(pán)空間的路徑上。臨時(shí)文件的名字一般是類(lèi)似ibXXXXXX，其中ib是固定前綴，XXXXXX是大小寫(xiě)字母以及數(shù)字的隨機(jī)組合。
在做online DDL中，我們是允許用戶(hù)對(duì)原表做DML操作的，即增刪改查。我們不能直接插入原表中，因此需要一個(gè)地方記錄對(duì)原表的修改操作，在DDL結(jié)束后，再應(yīng)用在新表上。這個(gè)記錄的地方就是online log，當(dāng)然如果改動(dòng)少的話，直接存在內(nèi)存里(參數(shù)innodb_sort_buffer_size可控制，同時(shí)這個(gè)參數(shù)也控制online log每個(gè)讀寫(xiě)塊的大小)面即可。這個(gè)onlinelog也是用臨時(shí)文件存，創(chuàng)建在innodb_tmpdir，最大大小為參數(shù)innodb_online_alter_log_max_size控制，如果超過(guò)這個(gè)大小了，DDL就會(huì)失敗。臨時(shí)文件的名字也類(lèi)似上述的排序臨時(shí)文件的名字。
在online DDL的最后階段，需要把排序完的文件和中途產(chǎn)生的DML全都應(yīng)用到一個(gè)中間文件上，中間文件文件名類(lèi)似#sql-ib53-522550444.ibd，其中#sql-ib是固定的前綴，53是InnoDB層的table id，522550444是隨機(jī)生成的數(shù)字。同時(shí)，在server層也會(huì)生成一個(gè)frm文件(8.0中沒(méi)有)，文件名類(lèi)似#sql-4d2b_2a.frm，其中#sql是固定前綴，4d2b是進(jìn)程號(hào)的十六進(jìn)制表示，2a是線程號(hào)的十六進(jìn)制表示(show processlist中的id)。因此我們也可以通過(guò)這個(gè)命名規(guī)則來(lái)找到哪個(gè)線程在做DDL。這里需要注意一點(diǎn)，這里說(shuō)的中間文件，其實(shí)算是一個(gè)臨時(shí)表，并不是上文說(shuō)中臨時(shí)文件，這些中間文件可以通過(guò)ls來(lái)查看。當(dāng)在DDL中的最后一步，會(huì)把這兩個(gè)臨時(shí)文件命名回原來(lái)的表名。正因?yàn)檫@個(gè)特性，所以當(dāng)數(shù)據(jù)庫(kù)中途crash的時(shí)候，可能會(huì)在磁盤(pán)上留下殘余無(wú)用的文件。遇到這種情況，可以先把frm文件重命名成與ibd文件一樣的名字，然后使用DROP TABLE#mysql50##sql-ib53-522550444`來(lái)清理殘余的文件。注意，如果不用drop命令，直接刪除ibd文件，可能會(huì)導(dǎo)致數(shù)據(jù)字典里面依然有殘余的信息，做法不太優(yōu)雅。當(dāng)然，在8.0中，由于使用了原子的數(shù)據(jù)字典，就不會(huì)出現(xiàn)這種殘余文件了。
BinLog只有在事務(wù)提交的時(shí)候才會(huì)寫(xiě)入到文件中，在沒(méi)提交前，會(huì)先放在內(nèi)存中(由參數(shù)binlog_cache_size控制)，如果內(nèi)存放慢了，就會(huì)創(chuàng)建臨時(shí)文件，使用方法也是先通過(guò)mkstemp創(chuàng)建，然后直接unlink，留一個(gè)句柄讀寫(xiě)。臨時(shí)文件名類(lèi)似MLXXXXXX，其中ML是固定前綴，XXXXXX是大小寫(xiě)字母以及數(shù)字的隨機(jī)組合。單個(gè)事務(wù)的BinLog太大，可能會(huì)導(dǎo)致整個(gè)BinLog的大小也過(guò)大，從而影響同步，因此我們需要盡可能控制事務(wù)大小。
有些操作，除了在引擎層需要依賴(lài)隱式臨時(shí)表來(lái)輔助復(fù)雜SQL的計(jì)算，在Server層，也會(huì)創(chuàng)建臨時(shí)文件來(lái)輔助，比如order by操作，會(huì)調(diào)用filesort函數(shù)。這個(gè)函數(shù)也會(huì)先使用內(nèi)存(sort_buffer_size)排序，如果不夠，就會(huì)創(chuàng)建一個(gè)臨時(shí)文件，輔助排序。文件名類(lèi)似MYXXXXXX，其中MY是固定前綴，XXXXXX是大小寫(xiě)字母以及數(shù)字的隨機(jī)組合。
在BinLog復(fù)制中，如果在主庫(kù)上使用了Load Data命令，即從文件中導(dǎo)數(shù)據(jù)，數(shù)據(jù)庫(kù)會(huì)把整個(gè)文件寫(xiě)入到RelayLog中，然后傳到備庫(kù)，備庫(kù)解析RelayLog，從中抽取出對(duì)應(yīng)的Load文件，然后在備庫(kù)上應(yīng)用。備庫(kù)上這個(gè)文件存儲(chǔ)的位置由參數(shù)slave_load_tmpdir控制。文檔中建議這個(gè)目錄不要配置在物理機(jī)的內(nèi)存目錄或者重啟后會(huì)刪除的目錄。因?yàn)閺?fù)制依賴(lài)這個(gè)文件，如果意外被刪除，會(huì)導(dǎo)致復(fù)制中斷。
除了上文所述的幾個(gè)地方外，還有其他幾個(gè)地方也會(huì)用到臨時(shí)文件：
*** tmpdir: *** 這個(gè)參數(shù)是臨時(shí)目錄的配置，在5.6以及之前的版本，臨時(shí)表/文件默認(rèn)都會(huì)放在這里。這個(gè)參數(shù)可以配置多個(gè)目錄，這樣就可以輪流在不同的目錄上創(chuàng)建臨時(shí)表/文件，如果不同的目錄分別指向不同的磁盤(pán)，就可以達(dá)到分流的目的。
*** innodb_tmpdir: *** 這個(gè)參數(shù)只要是被DDL中的排序臨時(shí)文件使用的。其占用的空間會(huì)很大，建議單獨(dú)配置。這個(gè)參數(shù)可以動(dòng)態(tài)設(shè)置，也是一個(gè)Session變量。
*** slave_load_tmpdir: *** 這個(gè)參數(shù)主要是給BinLog復(fù)制中Load Data時(shí)，配置備庫(kù)存放臨時(shí)文件位置時(shí)使用。因?yàn)閿?shù)據(jù)庫(kù)Crash后還需要依賴(lài)Load數(shù)據(jù)的文件，建議不要配置重啟后會(huì)刪除數(shù)據(jù)的目錄。
*** internal_tmp_disk_storage_engine: *** 當(dāng)隱式臨時(shí)表被轉(zhuǎn)換成磁盤(pán)臨時(shí)表時(shí)，使用哪種引擎，默認(rèn)只有MyISAM和InnoDB。5.7及以后的版本才支持。8.0.16版本后取消的這個(gè)參數(shù)。
*** internal_tmp_mem_storage_engine: *** 隱式臨時(shí)表在內(nèi)存時(shí)用的存儲(chǔ)引擎，可以選擇Memory或者Temptable引擎。建議選擇新的Temptable引擎。
*** default_tmp_storage_engine: *** 默認(rèn)的顯式臨時(shí)表的引擎，即用戶(hù)通過(guò)SQL語(yǔ)句創(chuàng)建的臨時(shí)表的引擎。
*** tmp_table_size: *** min(tmp_table_size,max_heap_table_size)是隱式臨時(shí)表的內(nèi)存大小，超過(guò)這個(gè)值會(huì)轉(zhuǎn)換成磁盤(pán)臨時(shí)表。
*** max_heap_table_size: *** 用戶(hù)創(chuàng)建的Memory內(nèi)存表的內(nèi)存限制大小。
*** big_tables: *** 內(nèi)存臨時(shí)表轉(zhuǎn)換成磁盤(pán)臨時(shí)表需要有個(gè)轉(zhuǎn)化操作，需要在不同引擎格式中轉(zhuǎn)換，這個(gè)是需要消耗的。如果我們能提前知道執(zhí)行某個(gè)SQL需要用到磁盤(pán)臨時(shí)表，即內(nèi)存肯定不夠用，可以設(shè)置這個(gè)參數(shù)，這樣優(yōu)化器就跳過(guò)使用內(nèi)存臨時(shí)表，直接使用磁盤(pán)臨時(shí)表，減少開(kāi)銷(xiāo)。
*** temptable_max_ram: *** 這個(gè)參數(shù)是8.0后才有的，主要是給Temptable引擎指定內(nèi)存大小，超過(guò)這個(gè)后，要么就轉(zhuǎn)換成磁盤(pán)臨時(shí)表，要么就使用自帶的overflow機(jī)制。
*** temptable_use_mmap: *** 是否使用Temptable的overflow機(jī)制。
感謝各位的閱讀！關(guān)于MySQL學(xué)習(xí)之臨時(shí)表是什么就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，讓大家可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到吧！
重慶分公司
重慶分公司
