Performance Tuning Project

Query Performance Tuning Resume Project Example

A query performance tuning engagement that diagnosed slow reporting queries with actual execution plans, redesigned covering indexes, and reduced average report runtime without schema redesign.

Execution PlansIndexesSSMSWait Stats

Free to start · No credit card required

MARCUS WEBB

SQL Developer

96% ATS matchATS

Project

Query tuning

Plan-driven
T-SQLSSMSExecution PlansDMVsSQL Server
  • Diagnosed slow queries with actual execution plans and DMVs.
  • Added covering indexes that eliminated key lookups.
  • Cut average report runtime with parameterized queries.

Why this project is valuable

Performance specialist signal

Query tuning shows you read plans, understand I/O, and fix bottlenecks—a core SQL developer skill.

Good ATS coverage

Supports execution plans, index design, DMVs, wait statistics, and query optimization keywords.

Measurable DBA partnership

Faster reports and lower CPU during business hours are outcomes operations teams value.

Good interview depth

Discuss plan operators, sargability, parameter sniffing, and index trade-offs.

Project overview

Query performance tuning is credible SQL developer resume material because slow queries are the most common escalation DBAs and app teams hand to database developers.

Reporting queries against a 200M-row fact table scanned wide indexes and spilled sorts to tempdb; analysis with actual plans and wait stats led to covering indexes, query rewrites for sargable predicates, and optional recompile hints for skewed parameters.

On a resume, that gives you ways to describe SSMS plan analysis, index INCLUDE columns, DMV investigation, and before/after duration metrics tied to business report SLAs.

Architecture overview

Project flow
1Find

Slow query identification

Query Store and DMVs surfaced top duration and CPU offenders during business hours.

2Analyze

Actual plan capture

SSMS actual plans revealed key lookups, implicit conversions, and sort spills.

3Index

Index redesign

Covering indexes aligned with filter and join columns to enable seek-plus-cover plans.

4Rewrite

Query rewrite

Predicates rewritten for sargability; unnecessary functions removed from WHERE clauses.

5Tune

Parameter sniffing fix

OPTION RECOMPILE applied selectively where skewed parameters caused bad cached plans.

6Verify

Regression monitoring

Post-change Query Store baselines confirmed sustained runtime improvement.

What this project includes

  • Query Store and DMV baseline analysis
  • Actual execution plan review in SSMS
  • Covering index design with INCLUDE columns
  • Sargability and predicate rewrites
  • Parameter sniffing mitigation
  • Before/after duration documentation

Tech stack

Performance tuning stacks on SQL Server center on plans, indexes, and DMVs—not visualization layers or ETL orchestrators alone.

SSMSExecution PlansT-SQLDMVsQuery StoreSQL Server

SSMS

Captures actual execution plans and compares operator costs before and after changes.

Execution Plans

Reveals lookups, spills, implicit conversions, and missing index suggestions.

T-SQL

Rewrites queries for sargable filters and efficient join orders.

DMVs

Surfaces wait stats, cache plans, and top resource-consuming statements.

Query Store

Tracks plan regressions and runtime trends after index deployment.

SQL Server

Hosts indexes, statistics, and the reporting workload under tuning.

Features implemented

Plan-driven diagnosis

Changes follow evidence from actual plans, not guesswork.

Covering indexes

Seek-plus-cover plans eliminate expensive key lookups on large tables.

Sargable predicates

Rewritten filters allow index seeks instead of scans.

Parameter sniffing awareness

Selective recompile handles skew without blanket plan instability.

Wait stat correlation

PAGEIOLATCH and CXPACKET waits informed index and parallelism choices.

Sustained monitoring

Query Store confirms improvements hold after statistics refreshes.

Resume bullet examples

These bullets present tuning as database performance engineering.

  • Diagnosed top-duration reporting queries using SSMS actual execution plans and Query Store, identifying key lookups and sort spills on a 200M-row fact table.
  • Designed covering indexes with INCLUDE columns that enabled seek-plus-cover plans and reduced average report runtime from 45s to under 8s.
  • Rewrote non-sargable predicates causing implicit conversions and applied selective OPTION RECOMPILE for skewed parameter workloads.
  • Documented before/after DMV and Query Store baselines for DBA review and ongoing regression monitoring.
Generate bullets from your project

Skills demonstrated

This project demonstrates execution plan analysis, index design, and SQL Server performance troubleshooting.

Diagnosis

execution plansDMVsQuery Storewait stats

Remediation

covering indexessargabilityquery rewritestatistics

Operations

SSMSparameter sniffingbaseline monitoringDBA collaboration

ATS keywords extracted from this project

Emphasize plan and index keywords over BI tool names.

query performance tuningexecution planscovering indexesSSMST-SQLDMVsQuery Storeindex designsargabilitySQL ServerSQL developerwait statistics

Interview questions based on this project

Tuning projects invite plan operator and index design questions.

What did the plan show was wrong?

Key lookups on a wide fact table after a non-covering seek, plus a sort spilling to tempdb because the index did not cover ORDER BY columns.

Why a covering index instead of a view?

The bottleneck was I/O on base table access; a covering index fixed the seek path without adding maintenance overhead of a new view layer.

How did you handle parameter sniffing?

Query Store showed plan instability across parameter values; OPTION RECOMPILE on the skewed report was safer than a blanket optimize-for-unknown.

How would you improve it further?

Partition the fact table by date to reduce scan scope for range-bound reports.

Common mistakes

Vague 'optimized queries'

Name plans, indexes, and measured runtime—not generic speed claims.

BI dashboard focus

Frame work around SQL Server queries and indexes, not Tableau.

Index sprawl without trade-offs

Acknowledge write overhead and how you limited index count.

No baseline metrics

Before/after duration or reads make impact credible.

FAQ

Is query tuning a good SQL developer project?

Yes. Performance troubleshooting is a high-signal skill for SQL developer and DBA-track roles.

Can I demo on Express edition?

Yes. Use a sizable sample database and honest plan captures; methodology matters more than production scale.

Should I mention Query Store?

Yes if you used it—it shows modern SQL Server monitoring familiarity.

How many bullets should I use?

Two to four bullets on diagnosis, index design, rewrites, and measured improvement.

Turn project details into resume evidence

Use this query tuning project to strengthen your SQL developer resume

Present execution plan analysis, index design, and recruiter-friendly performance outcomes with stronger keyword alignment.

Free to start · No credit card required