Exchange Spill 事件類別
適用於:SQL ServerAzure SQL DatabaseAzure SQL 受控執行個體
Exchange Spill 事件類別表示平行查詢計劃中通訊緩衝區已暫時寫入 tempdb 資料庫。 只有在查詢計劃有多個範圍掃描時,才會發生此情況。
一般而言,產生這類範圍掃描的 Transact-SQL 查詢有許多 BETWEEN 運算子,每個運算子都會從資料表或索引中選取一系列資料列。 或者,您可以使用運算式來取得多個範圍,例如 (T.a > 10 AND T.a < 20) OR (T.a > 100 AND T.a < 120)。 此外,查詢計劃必須要求依序掃描這些範圍,因為 T.a 上有 ORDER BY 子句,或因為計畫內的反覆運算器需要依排序次序取用 Tuple。
當這類查詢的查詢計劃有多個 Parallelism 運算子時,平行處理原則 運算子所使用的 記憶體通訊緩衝區就會滿,而且可能會發生查詢的執行進度停止的情況。 在此情況下,其中 一個 Parallelism 運算子會將其輸出緩衝區 寫入 tempdb (稱為 交換溢出 的作業),以便從部分輸入緩衝區取用資料列。 最後,當取用者準備好取用資料列時,溢出的資料列會傳回給取用者。
非常罕見地,多個交換溢出可能發生在同一個執行計畫中,導致查詢執行速度緩慢。 如果您在相同的查詢計劃執行中注意到超過五個溢出,請連絡您的支援專業人員。
Exchange 溢出有時是暫時性的,而且在資料散發變更時可能會消失。
有數種方式可避免交換溢出事件:
如果您不需要排序結果集,請省略 ORDER BY 子句。
如果需要 ORDER BY,請從 ORDER BY 子句中排除參與多個範圍掃描的資料行(上述範例中的 T.a)。
使用索引提示,強制優化器在有問題的資料表上使用不同的存取路徑。
重寫查詢以產生不同的查詢執行計畫。
藉由將 MAXDOP = 1 選項新增至查詢或索引作業的結尾,強制執行查詢。 如需詳細資訊,請參閱 設定平行處理原則的最大程度伺服器組態選項 和 設定平行索引作業 。
重要
若要判斷查詢最佳化工具產生執行計畫時發生 Exchange Spill 事件的位置 ,您也應該在追蹤中收集 Showplan 事件類別。 您可以選擇任何 Showplan 事件類別,但 Showplan Text 和 Showplan Text (Unencoded) 事件類別除外,不會傳回節點識別碼。 Showplan 中的節點識別碼會識別查詢最佳化工具在產生查詢執行計畫時執行的每個作業。 這些作業稱為運算子,而 Showplan 中的每個運算子都有節點識別碼。 Exchange Spill 事件的 ObjectID 資料行 會對應至 Showplans 中的節點識別碼,讓您可以判斷哪一個運算子或作業會造成錯誤。
Exchange Spill 事件類別資料行
資料行名稱 | 資料類型 | 描述 | 資料行識別碼 | 可篩選 |
---|---|---|---|---|
ApplicationName | nvarchar | 建立 SQL Server 實例之連線的用戶端應用程式名稱。 此資料行會填入應用程式所傳遞的值,而不是程式顯示的名稱。 | 10 | Yes |
ClientProcessID | int | 主機電腦指派給執行用戶端應用程式的進程識別碼。 如果用戶端提供用戶端進程識別碼,就會填入此資料行。 | 9 | Yes |
DatabaseID | int | 如果指定的實例未發出 USE database 語句,則為 USE database 語句或預設資料庫所指定的資料庫識別碼。 如果在追蹤中擷取到 ServerName 資料行且伺服器可用,SQL Server Profiler 便會顯示資料庫的名稱。 請使用 DB_ID 函數判斷資料庫的值。 | 3 | Yes |
DatabaseName | nvarchar | 使用者語句執行所在的資料庫名稱。 | 35 | Yes |
EventClass | int | 事件種類 = 127。 | 27 | No |
EventSequence | int | 要求內指定事件的順序。 | 51 | No |
EventSubClass | int | 事件子類別的類型。 1=溢出開始 2=溢出結束 |
21 | Yes |
GroupID | int | SQL 追蹤事件引發之工作負載群組的識別碼。 | 66 | Yes |
HostName | nvarchar | 用戶端執行所在的電腦名稱稱。 如果用戶端提供主機名稱,則會填入此資料行。 若要判斷主機名稱,請使用 HOST_NAME 函數。 | 8 | Yes |
IsSystem | int | 指出事件發生在系統進程或使用者進程上。 1 = 系統,0 = 使用者。 | 60 | Yes |
LoginName | nvarchar | 使用者登入的名稱(SQL Server 安全性登入或網域 > \ < 使用者名稱 > 形式的 < Windows 登入認證)。 | 11 | Yes |
LoginSid | image | 已登入使用者的安全性識別碼(SID)。 您可以在 master 資料庫的 syslogins 資料表 中找到 此資訊。 每一個 SID 對於伺服器中的每個登入而言都是唯一的。 | 41 | Yes |
NTDomainName | nvarchar | 使用者所屬的 Windows 網域。 | 7 | Yes |
NTUserName | nvarchar | Windows 使用者名稱。 | 6 | Yes |
Exchange Spill | int | 物件的系統指派識別碼。 會對應至 Showplans 中的節點識別碼。 | 22 | Yes |
RequestID | int | 包含 語句的要求識別碼。 | 49 | Yes |
ServerName | nvarchar | 要追蹤之 SQL Server 實例的名稱。 | 26 | No |
SessionLoginName | nvarchar | 產生會話之使用者的登入名稱。 例如,如果您使用 Login1 連接到 SQL Server,並以 Login2 的形式執行語句, SessionLoginName 會顯示 Login1,而 LoginName 會顯示 Login2。 此資料行會顯示 SQL Server 和 Windows 登入。 | 64 | Yes |
SPID | int | 事件發生所在之工作階段的識別碼。 | 12 | Yes |
StartTime | datetime | 如果有的話,事件開始的時間。 | 14 | Yes |
TransactionID | bigint | 交易的系統指派識別碼。 | 4 | Yes |
XactSequence | bigint | 描述目前交易的權杖。 | 50 | Yes |
另請參閱
sp_trace_setevent (Transact-SQL)
設定索引選項
ALTER INDEX (Transact-SQL)
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應