Developer ToolsFree worksheetPDF, Excel, Word export

SQL Query Tuning Log Worksheet

Tuning without records leads to folklore. This log captures what you changed, the measured before and after, and the percent gain, so you can show what worked and repeat it.

Download:

Query or report	Change made	Before (ms) (ms)	After (ms) (ms)	Reads before	Reads after	Time improvement	Reads improvement	Date
						93.2%	96.1%
						83.9%	88.8%
						77.7%	83.8%
						64.4%	47.4%

Average time improvement

79.8%

Average reads improvement

79%

Total before (ms)

150,100

Total after (ms)

26,050

Overall time saved

82.6%

Measure before and after on comparable data and with a warm cache for both runs, or clear it consistently. Logical reads from SET STATISTICS IO are a steadier measure than elapsed time. The example figures are illustrative.

Get a second look at slow queries

Optional: share your top slow queries and we will suggest likely causes and safe fixes.

Optional. The tool and every export work without this. No spam.

How to use the log

Before changing anything, capture elapsed time and logical reads for the query on representative data. Make one change, measure again, and enter both sets of numbers. The worksheet computes the improvement percentage for time and reads, plus an overall time saved figure weighted by total runtime.

Formula and interpretation

Improvement percent equals before minus after, divided by before, times 100. A drop from 18,400 ms to 1,250 ms is about a 93 percent improvement. Compare the time gain with the reads gain: if time fell but reads did not, the gain may come from caching or parallelism rather than a better plan, and it may not hold under load.

Change one thing at a time
Use logical reads as the stable metric
Record the plan operator that changed, such as scan to seek
Retest after statistics refresh and after data growth

Typical wins on ERP databases

Common causes of slow ERP queries are functions wrapped around indexed columns, such as converting a date column inside the WHERE clause, implicit data type conversions, missing indexes on foreign keys, stale statistics and unbounded date ranges. Document the cause next to each change so the lesson transfers to the next query.

Common mistakes

Adding an index for each slow query can slow inserts and updates on busy transactional tables, and some ERP vendors restrict custom indexes or may overwrite them in upgrades. Check support terms, test on a copy, and keep the log so indexes can be reviewed and removed if they no longer help.

Frequently Asked Questions

Which metric is best for tuning?

Logical reads and CPU time are more repeatable than elapsed time, which varies with load and caching. Record elapsed time too because users feel it, but base decisions on reads and plan changes.

Can I add indexes to a vendor ERP database?

Often yes, but check your vendor support terms first. Some vendors manage indexes themselves or may drop custom ones on upgrade. Document every custom index and plan to retest after upgrades.

How many test runs should I take?

Run at least three times and record a typical value, noting whether the cache was warm. Compare like with like. A single lucky run proves nothing.

What if the improvement is small?

Log it anyway. A change that gave 5 percent and cost an extra index is a useful lesson, and a record stops the same experiment being repeated.

If performance work keeps landing on a few people, we can help you review the slowest queries and set up monitoring that flags regressions after upgrades.

Talk to an Expert Explore More Free Tools

Related Tools

Developer Tools

More Developer Tools tools

See all

Back to All Tools