臨時表和SQL SELECT性能

Question

為什么使用帶有SELECT語句的臨時表可以改善邏輯I / O數量？ 它不會增加數據庫的點擊量而不是減少它。 這是因為'問題'被分解成了幾個部分嗎？ 我想知道幕后發生了什么。

Answer 1

沒有一般的答案。 這取決於臨時表的使用方式。

臨時表可以通過緩存在批處理中多次使用的復雜過濾器/連接之后創建的行來減少IO。 這樣，當只需要一部分記錄時，DB可以避免多次命中基表。

臨時表可以通過存儲以后從未在查詢中使用的記錄來增加IO，或者通過占用引擎緩存中可能被其他數據更好地使用的大量空間來增加IO。

創建臨時表以使用其所有內容一次比在主查詢中包含temp的查詢要慢，因為查詢優化器無法看到臨時表，並且它強制（可能）不必要的數據假脫機而不是允許它從源表流式傳輸。

Answer 2

我將假設臨時表是指WHERE子句中的子選擇。 （這被稱為半連接操作，您通常可以在查詢的文本執行計划中看到它。）

當查詢優化器遇到子選擇/臨時表時，它會對如何處理該數據做出一些假設。 本質上，優化器將創建一個執行計划，該計划在子選擇的結果集上執行連接，從而減少需要從其他表讀取的行數。 由於行數較少，查詢引擎能夠從磁盤/內存中讀取較少的頁面並減少所需的I / O量。

Answer 3

AFAIK，至少使用mysql，tmp表保存在RAM中，使SELECT比任何撞擊HD的速度快得多

Answer 4

有一類問題，在數據庫端的集合結構中構建結果比將結果的部分返回給客戶端更為可取，每個部分都需要進行往返。

例如：任意深度遞歸關系（boss）

還有另一類查詢問題，其中數據不會也不會以使查詢高效運行的方式編制索引。 將結果拉入可以自定義方式索引的集合結構將減少這些查詢的邏輯IO。