What is WorkTable in SQL Server? – Interview Question of the Week #146

Question: What is a Worktable in SQL Server, and why can it appear in SET STATISTICS IO when my query names no Worktable?

Answer: I had been waiting to write about this question. I keep this interview series to questions I actually hear in interviews or in my SQL Server performance workshop, and at last this one arrived.

The original demonstration used AdventureWorks2014, enabled I/O messages, and crossed the Product table with itself:

USE AdventureWorks2014;
GO
SET STATISTICS IO ON;
GO
SELECT *
FROM Production.Product AS p
CROSS JOIN Production.Product AS p1;
GO
SET STATISTICS IO OFF;

Run a cross join only in a safe sample environment; it can produce far more rows than you expect. In my historical run, SSMS reported Product and a second entry called Worktable. That raised the real interview question: where did this other table come from?

Table 'Product'.   Scan count 2, logical reads 30, ...
Table 'Worktable'. Scan count 1, logical reads 8110, ...

The same example in a current sample database

I ran the same cross join in AdventureWorks2025 on SQL Server 2025. It returned 254,016 rows and again reported 8,110 logical reads for the Worktable. These are observations from this sample run, not promised counts for every installation.

USE AdventureWorks2025;

SET STATISTICS IO ON;

SELECT *
FROM Production.Product AS p
CROSS JOIN Production.Product AS p1;

SET STATISTICS IO OFF;

The complete I/O messages from that run were:

Table 'Product'. Scan count 2, logical reads 30, physical reads 1, page server reads 0, read-ahead reads 20, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.
Table 'Worktable'. Scan count 1, logical reads 8110, physical reads 0, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.

Actual Table Spool: Lazy Spool, 503 rewinds. Captured in SSMS on SQL Server 2025.

The actual plan contains a Table Spool with the logical operation Lazy Spool. Its properties show 503 rewinds. The plan’s row counts and STATISTICS IO’s logical-page reads measure different things.

SQL Server can create an internal worktable to support an operation in the execution plan, such as a spool, sort, or cursor. It lives in tempdb and is managed by the engine. You do not have to name it in the SQL, and it is not the same thing as a user-created #temp table.

Do not infer too much from the I/O line alone. A Worktable entry tells you that the plan used an internal structure. The logical-read count is not automatically the number of physical disk reads, and the entry alone does not prove a memory-grant spill. Inspect the actual execution plan and any warnings before attributing a slow query to a particular operator or to tempdb pressure. Plan choice and I/O counts may differ by version, data size, indexes, and settings.

The short answer for an interview is: a Worktable is an engine-created internal staging structure in tempdb. The useful follow-up question is which plan operation needed it in this particular execution.

References: Microsoft tempdb internal objects and task-level internal-object usage.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.