Why TempDB Is Slowing Down Your Entire Server (And You Don’t Notice!) π₯
π Why TempDB Is Slowing Down Your Entire Server (And You Don’t Notice) π₯
Hi SQL Server Guys,
π If you missed my previous post, check it out here:
Nested Loop vs Hash Join vs Merge Join – The Truth Nobody Explains
The usual intro...
Your server is slow.
CPU looks fine.
IO looks fine.
Execution plan looks… acceptable.
π So what’s killing performance?
TempDB.
And the worst part?
π You often don’t even see it.
π§ What is TempDB really?
TempDB is a shared system database used by SQL Server for temporary operations.
It is involved in a lot of aspects:
- Temporary tables (#temp)
- Table variables
- Sorting (ORDER BY)
- Hash operations (JOIN / AGG)
- Spills to disk
- Version Store (snapshot isolation)
π£ TempDB is not optional: It is involved in almost every complex query.
⚙️ When SQL Server Uses TempDB
SQL Server uses TempDB whenever memory is not enough or when intermediate results are required.
- Large SORT operations
- Hash joins / aggregations
- Row versioning
- Spool operators
π If memory is insufficient then SQL Server spills to TempDB (no good!)
π₯ The Silent Killer: Spills
A spill happens when SQL Server runs out of memory and writes data to TempDB.
Types of spills:
- Sort Spill
- Hash Spill
π£ Disk is thousands of times slower than memory.
π A query that should run in milliseconds can suddenly take seconds.
π₯ Temp Tables & Table Variables
Temp tables are heavily used in real-world workloads:
CREATE TABLE #TempOrders
(
id INT,
amount MONEY
);
INSERT INTO #TempOrders
SELECT id, amount
FROM Orders;
π Every insert = writes into TempDB π Every index = more writes
π£ Temp tables are not “free memory”… they are real IO operations.
π₯ Version Store (Hidden Beast)
When using:
- READ COMMITTED SNAPSHOT
- SNAPSHOT ISOLATION
SQL Server stores row versions in TempDB.
π£ Long transactions = massive TempDB growth
π This is one of the most common production issues.
⚠️ Common Mistakes
- Too few TempDB files (one mdf file per CPU? ...we will see in next posts)
- Slow disk (no SSD)
- No monitoring of spills
- Overuse of temp tables
- Ignoring version store growth
π£ TempDB contention can slow down the entire instance. Keep in mind that all the databaes shares the SAME TempDB Databases!
π Summary of the Improvements Across SQL Server Versions
- SQL Server 2016+ → automatic TempDB configuration improvements
- SQL Server 2019 → memory-optimized TempDB metadata
- SQL Server 2022+ → better spill handling and memory grants
- SQL Server 2025 → improved parallelism + TempDB contention reduction
π But even with improvements bad queries still kill TempDB.
π§ͺ Benchmark – Spill Impact
| Scenario | Execution Time | TempDB Writes |
|---|---|---|
| No Spill | 123 ms | Low |
| Sort Spill | 840 ms | High |
| Hash Spill | 1270 ms | Very High |
π£ Same query. Same data. Just less memory → 10x slower.
π How to Detect TempDB Problems
SELECT
SUM(user_object_reserved_page_count) * 8 AS KB_User,
SUM(internal_object_reserved_page_count) * 8 AS KB_Internal,
SUM(version_store_reserved_page_count) * 8 AS KB_Version
FROM sys.dm_db_file_space_usage;
π Monitor:
- Spills (execution plan warnings)
- TempDB growth
- Wait stats (PAGELATCH, WRITELOG)
π£ My Final Thought
“TempDB is not just a temp space…
it’s the hidden engine behind your performance.”
π If TempDB is slow… everything is slow.

Comments
Post a Comment