以MySQL 8.0 來說，通過查看 8.0 的官方文檔得知，8.0 的臨時表空間分為會話臨時表空間和全局臨時表空間，會話臨時表空間存儲用戶創(chuàng)建的臨時表和當(dāng) InnoDB 配置為磁盤內(nèi)部臨時表的存儲引擎時由優(yōu)化器創(chuàng)建的內(nèi)部臨時表，當(dāng)會話斷開連接時，其臨時表空間將被截斷并釋放回池中；也就是說，在 8.0 中有一個專門的會話臨時表空間，當(dāng)會話被殺掉后，可以回收磁盤空間；而原來的 ibtmp1 是現(xiàn)在的全局臨時表空間，存放的是對用戶創(chuàng)建的臨時表進(jìn)行更改的回滾段，在 5.7 中 ibtmp1 存放的是用戶創(chuàng)建的臨時表和磁盤內(nèi)部臨時表；
公司主營業(yè)務(wù)：成都做網(wǎng)站、網(wǎng)站設(shè)計、移動網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。創(chuàng)新互聯(lián)是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊有機(jī)會用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)推出興隆臺免費(fèi)做網(wǎng)站回饋大家。
也就是在 8.0 和 5.7 中 ibtmp1 的用途發(fā)生了變化，5.7 版本臨時表的數(shù)據(jù)存放在 ibtmp1 中，在 8.0 版本中臨時表的數(shù)據(jù)存放在會話臨時表空間，如果臨時表發(fā)生更改，更改的 undo 數(shù)據(jù)存放在 ibtmp1 中；
實驗驗證：將之前的查詢結(jié)果保存成臨時表，對應(yīng)會話是 45 號，通過查看對應(yīng)字典表，可知 45 號會話使用了 temp_8.ibt 這個表空間，通過把查詢保存成臨時表，可以用到會話臨時表空間，如下圖：
下一步殺掉 45 號會話，發(fā)現(xiàn) temp_8.ibt 空間釋放了，變?yōu)榱顺跏即笮?，狀態(tài)為非活動的，證明在 mysql8.0 中可以通過殺掉會話來釋放臨時表空間。
總結(jié)：在 mysql5.7 時，殺掉會話，臨時表會釋放，但是僅僅是在 ibtmp 文件里標(biāo)記一下，空間是不會釋放回操作系統(tǒng)的。如果要釋放空間，需要重啟數(shù)據(jù)庫；在 mysql8.0 中可以通過殺掉會話來釋放臨時表空間。
InnoDB使用會話臨時表空間和全局臨時表空間。
在InnoDB配置為磁盤內(nèi)部臨時表的存儲引擎時，會話臨時表空間存儲用戶創(chuàng)建的臨時表和優(yōu)化器創(chuàng)建的內(nèi)部臨時表。從 MySQL 8.0.16 開始，用于磁盤內(nèi)部臨時表的存儲引擎固定為InnoDB。（之前，存儲引擎由internal_tmp_disk_storage_engine的值決定 ）
在第一次請求創(chuàng)建磁盤臨時表時會話臨時表空間從臨時表空間池中被分配給會話。一個會話最多分配兩個表空間，一個用于用戶創(chuàng)建的臨時表，另一個用于優(yōu)化器創(chuàng)建的內(nèi)部臨時表。分配給會話的臨時表空間用于會話創(chuàng)建的所有磁盤臨時表。當(dāng)會話斷開連接時，其臨時表空間將被截斷并釋放回池中。服務(wù)器啟動時會創(chuàng)建一個包含 10 個臨時表空間的池。池的大小永遠(yuǎn)不會縮小，并且表空間會根據(jù)需要自動添加到池中。臨時表空間池在正常關(guān)閉或中止初始化時被刪除。會話臨時表空間文件在創(chuàng)建時大小為 5 頁，并且具有.ibt文件擴(kuò)展名。
InnoDB為會話臨時表空間保留了40 萬個空間 ID。因為每次啟動服務(wù)器時都會重新創(chuàng)建會話臨時表空間池，所以會話臨時表空間的空間 ID 在服務(wù)器關(guān)閉時不會保留，并且可以重復(fù)使用。
innodb_temp_tablespaces_dir 變量定義了創(chuàng)建會話臨時表空間的位置。默認(rèn)位置是 #innodb_temp數(shù)據(jù)目錄中的目錄。如果無法創(chuàng)建臨時表空間池，則會拒絕啟動。
在基于語句的復(fù)制 (SBR) 模式下，在副本上創(chuàng)建的臨時表駐留在單個會話臨時表空間中，該臨時表空間僅在 MySQL 服務(wù)器關(guān)閉時被截斷。
INNODB_SESSION_TEMP_TABLESPACES 表提供有關(guān)會話臨時表空間的元數(shù)據(jù)。
該INFORMATION_SCHEMA.INNODB_TEMP_TABLE_INFO表提供有關(guān)在InnoDB實例中處于活動狀態(tài)的用戶創(chuàng)建的臨時表的元數(shù)據(jù)。
全局臨時表空間 ( ibtmp1) 存儲對用戶創(chuàng)建的臨時表所做的更改的回滾段。
innodb_temp_data_file_path 變量定義了全局臨時表空間數(shù)據(jù)文件的相對路徑、名稱、大小和屬性。如果沒有為innodb_temp_data_file_path指定值 ，則默認(rèn)行為是創(chuàng)建innodb_data_home_dir目錄中命名為ibtmp1的單個自動擴(kuò)展數(shù)據(jù)文件。初始文件大小略大于 12MB。
全局臨時表空間在正常關(guān)閉或中止初始化時被刪除，并在每次服務(wù)器啟動時重新創(chuàng)建。全局臨時表空間在創(chuàng)建時會收到一個動態(tài)生成的空間 ID。如果無法創(chuàng)建全局臨時表空間，則拒絕啟動。如果服務(wù)器意外停止，則不會刪除全局臨時表空間。在這種情況下，數(shù)據(jù)庫管理員可以手動刪除全局臨時表空間或重新啟動 MySQL 服務(wù)器。重新啟動 MySQL 服務(wù)器會自動刪除并重新創(chuàng)建全局臨時表空間。
全局臨時表空間不能駐留在原始設(shè)備上。
INFORMATION_SCHEMA.FILES提供有關(guān)全局臨時表空間的元數(shù)據(jù)。發(fā)出與此類似的查詢以查看全局臨時表空間元數(shù)據(jù)：
默認(rèn)情況下，全局臨時表空間數(shù)據(jù)文件會自動擴(kuò)展并根據(jù)需要增加大小。
要確定全局臨時表空間數(shù)據(jù)文件是否正在自動擴(kuò)展，請檢查以下 innodb_temp_data_file_path 設(shè)置：
要檢查全局臨時表空間數(shù)據(jù)文件的大小，請使用與此類似的查詢來查詢INFORMATION_SCHEMA.FILES表：
TotalSizeBytes顯示全局臨時表空間數(shù)據(jù)文件的當(dāng)前大小。
或者，檢查操作系統(tǒng)上的全局臨時表空間數(shù)據(jù)文件大小。全局臨時表空間數(shù)據(jù)文件位于 innodb_temp_data_file_path 變量定義的目錄中。
要回收全局臨時表空間數(shù)據(jù)文件占用的磁盤空間，請重新啟動 MySQL 服務(wù)器。重新啟動服務(wù)器會根據(jù)innodb_temp_data_file_path定義的屬性刪除并重新創(chuàng)建全局臨時表空間數(shù)據(jù)文件 。
要限制全局臨時表空間數(shù)據(jù)文件的大小，請配置 innodb_temp_data_file_path以指定最大文件大小。例如：
配置 innodb_temp_data_file_path 需要重新啟動服務(wù)器。
在mysql中，也出現(xiàn)了類似oracle中的表空間概念。
不過二者好像不同？具體不太清楚oracle是怎么回事。
mysql表空間是什么概念呢？
開啟了Innodb的innodb_file_per_table這個參數(shù)之后【innodb_file_per_table = 1】，也就是啟用InnoDB的獨(dú)立表空間模式，便于管理。此時，在新建的innodb表的數(shù)據(jù)庫目錄下會多出來一個.ibd這個文件。這個就是此時的數(shù)據(jù)文件了。mysql會把這個innodb表的數(shù)據(jù)存放在這個文件中。并且每個innodb表此時都會對應(yīng)這么一個ibd文件。
看官方文檔：
If innodb_file_per_table is disabled (the default), InnoDB creates tables in the system tablespace. Ifinnodb_file_per_table is enabled, InnoDB creates each new table using its own .ibd file for storing data and indexes, rather than in the system tablespace.
那么這樣做有什么好處呢？
可以實現(xiàn)單表在不同的數(shù)據(jù)庫之間移動。具體怎么移動呢？假設(shè)有兩個數(shù)據(jù)庫，一個test，一個tt。
InnoDB 默認(rèn)會將所有的數(shù)據(jù)庫InnoDB引擎的表數(shù)據(jù)存儲在一個共享空間中：ibdata1，這樣就感覺不爽，增刪數(shù)據(jù)庫的時候，ibdata1文件不會自動收縮，單個數(shù)據(jù)庫的備份也將成為問題。通常只能將數(shù)據(jù)使用mysqldump 導(dǎo)出，然后再導(dǎo)入解決這個問題。共享表空間在Insert操作上少有優(yōu)勢。其它都沒獨(dú)立表空間表現(xiàn)好。當(dāng)啟用獨(dú)立表空間時，請合理調(diào)整一 下innodb_open_files 的值。
-------------------------------------------------------------------------------
需要說明的是：
1、設(shè)置了獨(dú)立表空間之后，如果改成了共享表空間，那么，此時如果執(zhí)行表的插入操作，數(shù)據(jù)會存放在哪里呢？
對于之前已經(jīng)存在了的表，還是存放在獨(dú)立表空間。對于新建的表，就會存放在共享表空間了。
2、如果一開始用了獨(dú)立表空間，后來改了innodb_file_per_table變量的值，改成獨(dú)立表空間了，那么數(shù)據(jù)如何存儲？
對于已經(jīng)存在了的innodb引擎的表來說，數(shù)據(jù)還是存放在共享表空間的，而此時如果創(chuàng)建了新的表，那么就會在數(shù)據(jù)庫的目錄中多出一個.ibd的文件用于存儲這個新表的數(shù)據(jù)。
總結(jié)上面的1、2，就是：原來的還是按照原來的方式存儲。新的表按照新的規(guī)則來存儲。
有些mysql版本(比如5.6.2)限制了重做日志大小為4GB。所以在你設(shè)置innodb_log_file_size為2G或者更多時，請先檢查一下MySQL的版本這方面的限制。
具體操作可以參考如下:
1.在my.cnf更改innodb_log_file_size
2.停止mysql服務(wù)器
3.刪除舊的日志,通過執(zhí)行命令rm -f /var/lib/mysql/ib_logfile*
4.啟動mysql服務(wù)器 – 應(yīng)該需要比之前長點(diǎn)的時間，因為需要創(chuàng)建新的事務(wù)日志。
mysql是數(shù)據(jù)庫，如果你的網(wǎng)站需要連接數(shù)據(jù)庫會用到這個，有些虛擬主機(jī)是主機(jī)商給你分配好數(shù)據(jù)庫，有些是需要自己分配空間，如果是需要自己創(chuàng)建數(shù)據(jù)庫的直接在數(shù)據(jù)庫管理面板創(chuàng)建就可以了，操作也很簡單，然后得到數(shù)據(jù)庫的地址和用戶名密碼，和網(wǎng)站鏈接就可以了。
內(nèi)存表有大小限制，內(nèi)存文件超過 my.ini 中設(shè)置以后，會自動轉(zhuǎn)換部分到硬盤。內(nèi)存表所占內(nèi)存以固定的大小分配空間，即使一個表中只有一條記錄，也可能占幾M空間。內(nèi)存表是有大小限制的，在 my.ini 中可以設(shè)置，當(dāng)內(nèi)存大小達(dá)到限制時，可能會報錯：#1114: The table ‘XXX’ is full 。上面是我實際遭遇到的，但是 my.ini 中有下面這段：
# Maximum size for internal (in-memory) temporary tables. If a table
# grows larger than this value, it is automatically converted to disk
# based table This limitation is for a single table. There can be many
# of them.
tmp_table_size=13M
重慶分公司
重慶分公司
