MKsql server / problems / tempdb-growth
Tempdb growth is usually a pressure signal, not just a file-management nuisance.
This page is for the point where tempdb keeps growing, spilling, or causing operational noise, but the team still needs to decide whether the real problem is setup, workload shape, version-store behavior, maintenance timing, or wider estate drift. The useful job is to stop treating tempdb as an isolated oddity and work out what pressure it is really carrying.
Related
Use the SQL Server tempdb guide for the deeper tempdb review, the SQL Server health check guide when tempdb is one part of wider operational drift, the SQL Server sizing guide when platform fit looks weak, and SQL Server health audit when tempdb is already part of a larger estate review.
What it usually looks like
Common cause classes
Safe first checks
Why this page exists
Teams usually land here because tempdb is growing, autogrowth is noisy, or performance incidents keep leaving tempdb fingerprints behind. At that point the useful question is not “how many tempdb files should we have?” It is “what is driving this pressure, and is tempdb badly configured or just telling the truth about something bigger?”
That is why this page stays narrow. Tempdb growth can come from weak setup, workload spills, row-versioning pressure, maintenance timing, or wider platform issues. The first job is to connect the growth pattern back to the workload story and decide whether the next step belongs in tempdb review, a broader health audit, or platform sizing work.
Best deeper pages
Longer review of tempdb role, file layout, sizing, growth, version-store pressure, and operational checks.
Read this if tempdb is one part of a larger estate review and the real question is broader operational risk.
Open this if tempdb pressure may be a symptom of wider platform fit, storage weakness, or capacity assumptions failing.
When outside help makes sense
This review is worth bringing in when tempdb growth is already part of a messier operational story, when the team cannot tell whether the issue is setup or workload pressure, or when inherited configuration debt needs a broader review instead of one isolated tempdb fix.
Tempdb keeps showing up alongside blocking, maintenance drift, storage concerns, or weak monitoring.
You need one review that ties tempdb behavior back to the wider estate instead of treating it as a standalone oddity.
The goal is a practical fix order, not more folklore about file counts.
Next step
If tempdb growth is part of a wider estate problem, use SQL Server health audit or go straight to contact with the growth pattern, when it happens, and whether you already know if version store, spills, or maintenance windows are involved.
If you need the deeper tempdb path first, start with the SQL Server tempdb guide.
If the bigger issue is poor visibility around the workload and the growth pattern, switch to SQL Server monitoring gaps.