Most developers immediately say: ❌ “Create an index.” ❌ “Increase RAM.” ❌ “Restart SQL Server.” ❌ “Rebuild all indexes.”

But as a DBA, I would ask a different question: 👉 What is the evidence telling us? Because SQL Server Performance Tuning ≠ Index Tuning.

It is a systematic process:

🔎 1. Identify the Problem What exactly is slow — query, SP, database, or server?

📊 2. Establish a Baseline Check CPU, duration, logical reads, physical reads and waits.

🖥️ 3. Check Server Health CPU → Memory → Disk I/O → TempDB → Transaction Log

⏳ 4. Analyze Waits & Blocking LCK_M_* → Blocking PAGEIOLATCH_* → I/O WRITELOG → Log I/O RESOURCE_SEMAPHORE → Memory Grants 🔍 5. Find Top Queries Use Query Store + DMVs to identify the real offenders.

📈 6. Read the Actual Execution Plan Look for: • Scans vs Seeks
• Key Lookups
• Bad cardinality estimates
• Sorts / Hashes • Spills
• Implicit conversions
• Parallelism

🎯 7. Find the Root Cause Possible causes: ➡️ Missing/incorrect indexes
➡️ Outdated statistics
➡️ Parameter sniffing ➡️ Non-SARGable predicates
➡️ Blocking/locking
➡️ TempDB bottlenecks ➡️ Poor query design

🛠️ 8. Apply the RIGHT Fix Not every slow query needs an index. Sometimes the solution is: ✅ Query rewrite
✅ Better index design
✅ Statistics update ✅ Parameter-sniffing fix ✅ Blocking resolution ✅ Schema/design improvement

📉 9. Validate the Result Always compare: Before → After CPU ↓ Duration ↓ Logical Reads ↓ Wait Time ↓ 🔄 10. Monitor Continuously A query that is fast today can become slow tomorrow because data, workload and execution plans change.

🔥 DBA Golden Rule Don't tune what you THINK is slow. Tune what the EVIDENCE proves is slow.