QUERY_EXECUTION_INDEX_SORT_EVENT_OPEN Wait Type in SQL Server

---

QUERY_EXECUTION_INDEX_SORT_EVENT_OPEN is recorded during parallel offline index builds, when the worker threads performing the sort synchronise access to the shared sort files and wait for each other to finish their portions. Index creation is substantially a giant sort, and in a parallel offline build that sort is divided across workers who must rendezvous.

It is index-maintenance machinery, visible only while offline builds run.

Is It a Problem?

Not intrinsically; it tracks the duration and parallelism of your offline index builds. It becomes informative when builds run long: heavy time here means workers spent real time waiting on each other at the sort, which usually points at skewed work distribution or the sort spilling and slowing unevenly.

If index build durations are acceptable, ignore it entirely.

Common Causes

• Parallel offline index creation and rebuilds doing their normal sort coordination.
• Skewed key distributions leaving one sort worker with the bulk of the data.
• Sort memory shortfalls pushing sort runs to disk (tempdb), stretching the slowest worker.

What To Do

1. For slow builds, check sort spill evidence during the build window (tempdb activity, memory grants for the build session).
2. Give big builds resources: run them in windows with memory headroom, and consider SORT_IN_TEMPDB placement and tempdb health.
3. Where the edition allows, online builds change the profile entirely (different waits, different trade-offs).
4. MAXDOP on the index statement bounds the coordination cost when skew is chronic.

How To See It

Rank it against everything else with Get-WaitStatistics; its presence maps one-to-one onto offline index build activity.

---