Database and Query Tuning

Database and query tuning is query-level work. A slow query log collected over working hours is grouped by total time per statement, then read plan by plan and rewritten.

Share your requirements

Finding the queries that matter

Ranking by total time and not by the slowest single example separates fixing a symptom from fixing the working day.

Grouped by shape

Statements are normalised, so the same query with different parameters is counted together.

Total over peak hours

Duration multiplied by frequency, measured during the window your team complains about.

The quiet ones

Queries that each take a moment but run constantly never appear in a slowest-first list.

Reading the plan, then rewriting

The execution plan shows what the database is doing. It often contradicts what the developer assumed.

Full scans

A filter that cannot use an index, often because a function was wrapped around the column.

Joins in the wrong order

Row estimates far from the real numbers send the planner down an expensive path.

Rewrites

Sub-queries become joins, distinct is removed, and columns nobody displays are dropped from the select.

Patterns that live in the code

Some of the worst query problems cannot be fixed in the database, because it is doing exactly what it was asked.

One query per row

A loop fetches a customer name for every line of a list, turning one screen into hundreds of round trips.

Fetching everything

Whole tables are loaded into memory so the application can filter them. Pagination solves this properly.

Counting badly

Row counts are recalculated on every page of a list, when an estimate or a stored total would do.

FAQ

Frequently asked questions

Do we need to switch off the application while queries are tuned?

No. Analysis runs against logs and a staging copy, and index changes are applied in an agreed window, online where the database supports it. Any downtime is planned in advance.

Our vendor says the queries are fine. How do we settle it?

With the plan and the log, which are not matters of opinion. The same evidence is shared, so your vendor can check each finding and need not take it on trust.

What if a report is slow because it reads a lot of data?

Then a faster query is not the answer. The report moves to a background job, a pre-computed summary or a replica, so it still runs without holding up order entry.

Talk to us

Tell us what you need.

Share your requirements and one of our engineers will come back to you within one business day.

No obligation
A reply within one business day
Your details stay private

Start with your requirements

Seven short steps that tell us what you need. An engineer reads them before getting in touch.

Share your requirements