A website database is slow: find the expensive query before changing the server

Locate the database boundary inside the page journey

Ask the authorized maintainer to compare the application request with the database work it triggers. Separate obtaining a connection, running database operations, waiting, transferring results and rendering the response. Record what the existing observations actually measure; a label such as Database time may combine several stages.

For the catalogue, use the same category, access context and dataset when comparing observations. Note whether the delay appears before results begin or after they have been retrieved. If the database stage is not the dominant delay, keep investigating the page journey rather than forcing a query diagnosis.

The WordPress performance triage guide covers broader causes. This workflow narrows the investigation to a specific database workload after there is evidence that the database boundary matters.

Identify a query pattern without publishing private data

Use the application’s existing authorized observability where possible. Ask for the query’s role, normalized structure, frequency and timing window, with sensitive values removed from shared evidence. A useful record might identify Availability lookup for each catalogue item without exposing customer names, account tokens or confidential product information.

A raw query log can contain more than the SQL structure. Agree who may access it, where it is retained and what must be redacted before sharing. Do not enable unrestricted production logging merely because a page is slow. Use a bounded investigation suited to the service’s permissions and operational constraints.

For the fictional catalogue, distinguish the category query from availability and accessory queries. Naming those roles makes the handoff actionable: the developer can trace which application component requests them instead of searching through an unlabelled collection of statements.

Read a plan without treating it as a benchmark

PostgreSQL’s EXPLAIN guide, resolving to version 18 on review, distinguishes estimated plans from execution measurements. Planner costs are not milliseconds. EXPLAIN ANALYZE actually executes the statement; it is not a harmless label for a read-only inspection of any production query.

Start with an authorized review of existing evidence and the appropriate non-executing plan where suitable. Let the maintainer decide whether an execution-based investigation is justified in an isolated, representative environment. Do not run a statement that changes records merely to obtain a more detailed plan.

MySQL 8.4 also documents EXPLAIN and execution-based analysis. Its output and options are engine-specific. Confirm the installed engine and version rather than copying PostgreSQL field interpretations or procedures into another system.

For the catalogue, ask which plan steps account for the relevant work and whether estimates fit the expected result shape. A scan label alone does not justify an index. The maintainer needs the query, data distribution and required result before proposing a structural change.

Distinguish waiting from expensive computation

PostgreSQL’s monitoring documentation exposes activity and wait information with observation and permission limits. An active query can be waiting; activity state and wait events answer related but different questions. A single snapshot should not become a complete incident history.

For the fictional catalogue, collect time-scoped observations around the affected request. If waiting is implicated, ask the maintainer to identify its dependency and business role before intervening. Killing a session, restarting the database or changing timeouts without that context can interrupt unrelated work.

If the symptom is a connection failure rather than slowness, use the database connection diagnosis guide. A service that cannot establish its database connection needs a different investigation from a connected service with an inefficient query.

Test a focused correction against the real workload

Ask the maintainer to state the proposed cause and correction before editing: reduce unnecessary repeated calls, revise the requested result, review an index candidate or address a confirmed dependency. Include a recovery route and a representative test workload. Avoid changing several independent factors at once.

Compare correctness as well as timing. The catalogue must still show the right products, ordering, availability and access-dependent details. A faster result that omits required records or serves inappropriate cached information is not an acceptable optimization.

The autoloaded options guide handles a specific WordPress workload. Do not substitute deleting settings for query evidence, and do not add indexes automatically because an unrelated warning is visible.

Close with a reproducible evidence handoff

Keep the affected page journey, normalized query role, observation window, engine version, plan type and proposed acceptance conditions together. Record what remains uncertain. These are proposed investigation exercises, not measurements performed on a reader’s database.

Accept a correction when the intended workload produces the correct result and the relevant observations support the claimed improvement. Keep any remaining connection, transfer or rendering delay visible instead of describing one improved query as proof that the whole website is fast.