在某些情況下，伺服器在處理sql語句時建立內部臨時表。使用者無法直接控制何時發生。
伺服器在以下條件下建立臨時表：
(evaluation有什麼特殊意思嗎？我翻譯成了評估)
要確定語句是否需要臨時表，請使用explain並檢查extra列以檢視是否顯示using temporary（請參見 第9.8.1節「使用explain優化查詢」）。對於派生或物理化的臨時表，explain不一定說using temporary。
當伺服器建立內部臨時表（在記憶體或磁碟上）時，會增加created_tmp_tables狀態變數。如果伺服器在磁碟上建立表（最初或通過轉換記憶體中的表），它會增加created_tmp_disk_tables狀態變數。
某些查詢條件阻止使用記憶體中臨時表，在這種情況下，伺服器會使用磁碟表：
伺服器不使用union符合特定條件語句的臨時表。相反，它保留了從臨時表建立唯一的資料結構進行必要的結果列的型別轉換。表沒有完全例項化，沒有行被寫入或讀取; 行直接傳送到客戶端。結果是減少了記憶體和磁碟要求，並且在將第一行傳送到客戶端之前的較小延遲，因為伺服器不需要等待直到最後乙個查詢塊被執行。explain優化器跟蹤輸出反映了此執行策略：union result查詢塊不存在，因為該塊對應於從臨時表讀取的部分。
這些條件符合條件union，無需臨時表：
用於臨時表的儲存引擎
內部臨時表可以在儲存記憶體中並且由memory儲存引擎處理，或者以innodb或myisam儲存引擎儲存在磁碟上。
如果表是內部臨時表並且被儲存在記憶體中，但是變得太大，mysql會自動將其轉換為磁碟表。記憶體中臨時表的最大大小由兩者中tmp_table_size和max_heap_table_size中較小的決定。這與使用create table顯式建立的記憶體表不同, 對於這樣的表，只有max_heap_table_size系統變數確定表允許增長的大小，並且沒有轉換為磁碟格式。
所述internal_tmp_disk_storage_engine系統變數確定伺服器使用哪個儲存引擎來管理的磁碟上的內部臨時表。允許的值為innodb（預設值）和myisam。
**注意**
使用 `internal_tmp_disk_storage_engine=innodb` 生成超過 `innodb` 行或列限制的臨時表的查詢,
如果返回行大小太大或列錯誤太多。解決方法是設定 `internal_tmp_disk_storage_engine` 為 `myisam`。
儲存器內臨時表由memory儲存引擎管理，儲存引擎使用固定長度的行格式。varchar和varbinary列值填充到最大列長度，實際上將它們儲存為char和binary列。
在磁碟上的臨時表由管理innodb或myisam儲存引擎（取決於internal_tmp_disk_storage_engine設定）。兩個引擎使用動態寬度行格式儲存臨時表。列只需要盡可能多的儲存空間，與使用固定長度行的磁碟表相比，減少了磁碟i/o和空間要求以及處理時間。
對於最初在記憶體中建立內部臨時表的語句，然後將其轉換為磁碟表，可能會通過跳過轉換步驟並在磁碟上建立表來實現更好的效能。big_tables系統變數可以用來強制內部臨時表的磁碟儲存。
翻譯的有問題的地方，請大家多多指教。
mysql 5 7 安裝（官方文件）
shell yum search libaio search for info shell yum install libaio install library shell groupadd mysql shell useradd r g mysql s bin false mysql shell ...
linux上MySQL5 7安裝文件
mysql安裝文件 mysql 5.7.17 1.el6.x86 64.rpm bundle.tar redhat6.6 rpm qa grep mysql rpm e mysql community common 5.7.17 1.el6.x86 64 nodeps 分別解除安裝已經安裝所有mys...
mysql57是什麼 關於mysql57的詳細介紹
簡介 php7 mysql57 nginx19 on ubuntu 1404 本文 前段時間php公升級到了7.0版本，據說很牛叉，比如效能較5.6提公升兩倍，記憶體占用低之類的，後來又看微博上說等到7.0.1才穩定。果不其然，很快就公升級了，最近才有時間折騰一下，在這裡做個總結。環境 1核1g主機...