# SQL Query Tuning Log Worksheet > Source: https://netray.co/tools/sql-query-tuning-log-worksheet > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer A tuning log that records the change, before and after runtime and logical reads, and calculates percent improvement. ## Category developer ## Audience - Database administrator - ERP developer - ERP analyst ## Tool **Kind:** worksheet **Mode:** editable **Columns:** #### Query or report **Key:** query **Type:** text #### Change made **Key:** change **Type:** select **Options:** - New index - Rewrite predicate - Remove function on column - Update statistics - Add filter or date range - Query hint or plan guide - Other #### Before (ms) **Key:** before_ms **Type:** number **Unit:** ms #### After (ms) **Key:** after_ms **Type:** number **Unit:** ms #### Reads before **Key:** before_reads **Type:** number #### Reads after **Key:** after_reads **Type:** number #### Time improvement **Key:** time_gain **Type:** number **Expr:** if(gt(before_ms,0),(before_ms - after_ms) / before_ms * 100,0) **Format:** percent #### Reads improvement **Key:** read_gain **Type:** number **Expr:** if(gt(before_reads,0),(before_reads - after_reads) / before_reads * 100,0) **Format:** percent #### Date **Key:** date **Type:** date **Rows:** **Query:** Open PO lines past due **Change:** Remove function on column **Before ms:** 18400 **After ms:** 1250 **Before reads:** 2450000 **After reads:** 96000 **Date:** 2026-09-03 **Query:** Inventory aging by site **Change:** New index **Before ms:** 92000 **After ms:** 14800 **Before reads:** 11800000 **After reads:** 1320000 **Date:** 2026-09-10 **Query:** Customer backlog by week **Change:** Add filter or date range **Before ms:** 31000 **After ms:** 6900 **Before reads:** 5200000 **After reads:** 840000 **Date:** 2026-09-17 **Query:** Job material shortage **Change:** Update statistics **Before ms:** 8700 **After ms:** 3100 **Before reads:** 780000 **After reads:** 410000 **Date:** 2026-10-01 **Totals:** #### Average time improvement **Key:** time_gain **Agg:** avg **Format:** percent #### Average reads improvement **Key:** read_gain **Agg:** avg **Format:** percent #### Total before (ms) **Key:** before_ms **Agg:** sum **Format:** number #### Total after (ms) **Key:** after_ms **Agg:** sum **Format:** number **Summary:** #### Overall time saved **Key:** overall **Expr:** if(gt(sum_before_ms,0),(sum_before_ms - sum_after_ms) / sum_before_ms * 100,0) **Format:** percent **Primary:** true **Notes:** 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. ## Content **Intro:** 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. **Sections:** #### How to use the log **Body:** 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 **Body:** 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. **Bullets:** - 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 **Body:** 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 **Body:** 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. **Cta:** 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. **Faq:** #### Which metric is best for tuning? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms sql tuning log template, query performance tracking excel, sql performance tuning worksheet, before after query runtime, slow query log template, database tuning change log, logical reads comparison worksheet --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json