Query optimisation.

Where Query optimisation fits on a long engagement.

Optimisation without a plan is guessing. The execution plan says whether the engine scanned or sought, where the row estimates diverged from reality, and which step actually consumed the time. Most optimisation effort spent without reading one is spent on the wrong part of the query.

Indexes are the first tool and the most over-applied. Every index accelerates reads and slows writes, and a table with fifteen indexes has a write cost nobody accounted for. The right number is the smallest set that serves the queries that matter, which requires knowing which those are.

What an assigned team does with Query optimisation.

The most valuable optimisation is often not optimisation. A query that is slow because it returns fifty thousand rows to a page showing twenty needs pagination, not an index; one recomputing the same aggregate hourly needs a materialised result.

Recognising that requires understanding what the query is for, which is product knowledge rather than database knowledge, and it accumulates in a standing assignment described in how an assignment runs.

What we use Query optimisation for.

• Plans read before changes are made Effort directed at the step that costs, rather than the line that looks suspicious.
• Index sets kept minimal The smallest set serving real queries, so write cost stays proportionate.
• Questioning the query itself Pagination or materialisation where the query should not be running as written.

How Query optimisation capacity is assigned.

Query work is assigned inside the discipline that owns the data layer, under managed data services where the database is the constraint.