What’s the issue?
SQL Server tracks file-level I/O performance through the dynamic management functions and views. For tempdb, slow read or write latency is particularly impactful because tempdb is shared by every database and every session on the instance and is involved in nearly every query that performs sorts, hash joins, spills, temporary tables, table variables, or version store activity.This finding identifies instances where one or more tempdb files (data or log) are experiencing average read or write latency above 100 ms, which is the default threshold used by sp_CheckTempdb.
Why is this a problem?
Slow tempdb storage produces broad performance impact across the instance because so many operations depend on tempdb. Queries that spill, use temporary tables, or rely on snapshot isolation all wait on tempdb I/O, and slow latency adds directly to query duration. Workloads that are otherwise well-tuned can appear sluggish for reasons that are not obvious without specifically checking tempdb performance.Sustained high latency on tempdb often indicates underlying storage problems that affect more than just tempdb. Shared storage volumes, virtualization layer issues, contention from other workloads on the same storage, and degrading drives can all produce elevated latency that affects every database on the affected storage. Tempdb is often the most visible symptom because of its high I/O volume, but the root cause is rarely tempdb-specific.
Slow tempdb writes also extend transaction durations indirectly. Operations that need to flush pages from the tempdb buffer pool to disk, write to the version store, or harden log records pay the slow-write cost on every commit that touches tempdb. The result is degraded throughput and increased lock contention because transactions hold resources longer than they should.
The 100 ms threshold is a conservative starting point for investigation. Modern storage on dedicated drives should typically deliver tempdb latency well below 10 ms for both reads and writes, and any sustained value above 100 ms indicates either misconfigured storage, contention from other workloads, or a hardware issue that needs to be addressed.
What should you do about this?
Review the storage layout to confirm tempdb is on dedicated, fast storage appropriate to its workload. Tempdb should not share storage with the operating system, the SQL Server binaries, or user database files where avoidable, and modern environments should use SSD or NVMe storage for tempdb to keep latency consistently low.Investigate workload patterns that produce heavy tempdb pressure, including queries that spill due to undersized memory grants, heavy use of large temporary tables, frequent operations under snapshot isolation, and unusually large sort or hash operations. Tuning queries to reduce tempdb usage reduces both latency symptoms and overall load on the storage.
Coordinate with the storage and infrastructure teams if the latency is the result of contention or hardware limits beyond what tempdb tuning can address.