Performance diagnostic · MySQL, MariaDB, Aurora MySQL

MySQL & Aurora Performance Diagnostic

Your database is slow, but the next change is unclear. This diagnostic investigates one agreed performance question and gives your team a prioritised plan based on the evidence available.

Suitable problems

The diagnostic covers MySQL, MariaDB and Amazon Aurora MySQL. Typical starting points:

  • Unexplained or intermittent query latency.
  • Recurring lock contention.
  • An indexing or query-performance question that needs deeper investigation.
  • Uncertainty about whether increasing database capacity addresses the underlying issue.
  • A client project requiring a specialist second opinion.

Scope is confirmed before work starts. Whether the diagnostic fits depends on the question and the evidence that can be made available; if it does not fit, I will say so.

Scope and process

  1. A short fit and scope review identifies the principal question and the outcome you need.
  2. We agree the environment, effort limit, evidence requirements, fee, and schedule.
  3. I review the relevant evidence within the agreed scope.
  4. Findings include their limitations, recommended actions, and validation steps.
  5. A technical handover helps your team — or your agency's team — understand and use the result.

One environment and one principal question, with the scope, fee, and schedule agreed before work begins.

Fixed fee, agreed after a short scope review.

What you receive

A written report and a technical handover. The report covers:

  • The question investigated and the scope of the review.
  • The evidence reviewed, and its limitations.
  • Findings that separate observation, hypothesis, and uncertainty.
  • Prioritised recommended actions and their prerequisites.
  • A plan for validating changes.
  • A technical handover.

The public sample shows the full structure with a synthetic scenario. Read the sample diagnostic.

DB-Ex · MySQL example Illustrative sample

Slow order history in a multi-tenant application

Question investigated

Why does the order-history page become slow for some tenants, and what should the team test first?

Findings (excerpt)

  • No index matches the filter and sort together
  • Deep pages use OFFSET
  • The slow tenants' execution plans are missing

Next step

Estimate the large-tenant plan with EXPLAIN FORMAT=JSON before any EXPLAIN ANALYZE.

Synthetic MySQL scenario; no customer data or measured results.

Read the MySQL sample →

Evidence and access

Evidence requirements are agreed after the initial enquiry, once the question is clear. Depending on the question they may include appropriately sanitised query examples, execution plans, metrics, and relevant configuration details.

Production access is not always necessary. Where access would help, its type and the handling of any data are agreed for the engagement. Please do not send credentials or sensitive data with your first enquiry.

Not included

The standard diagnostic does not include:

  • Production changes and deployment of recommendations.
  • Emergency response or on-call cover.
  • Continuous monitoring and ongoing support.
  • Unlimited investigation or an open-ended implementation project.
  • Guaranteed improvement percentages, cost reductions, or root-cause certainty.

Your team or implementation partner owns change execution, unless a separate, explicitly agreed scope says otherwise.

Questions

Is the diagnostic suitable for an agency's client project?

Yes. The agency keeps the client relationship and the implementation work; I carry out the agreed investigation and hand the findings to the agency's team. Customer approval, permitted access and how evidence is shared are agreed before work starts.

Does it include implementation?

No. The diagnostic ends with findings, prioritised recommendations, validation steps and a handover. Your team or your implementation partner makes the changes. Any further involvement would be a separate, explicitly agreed scope.

Is production access required?

Not necessarily. Many questions can be investigated from evidence your team collects, such as sanitised queries, execution plans, metrics and configuration. If access would help, the type of access and how data is handled are agreed for the engagement.

What happens if the evidence is insufficient?

The report says so. It states what could and could not be established, what evidence is missing, and how to collect it. Remaining uncertainty is part of a useful result, not something hidden.

Do I need an ongoing support contract?

No. The diagnostic is a standalone, fixed-scope engagement.

How are the scope, fee, and schedule agreed?

After your enquiry, a short fit and scope review identifies the principal question. You then receive a written proposal with the environment, effort limit, evidence requirements, fixed fee and schedule. Work starts only once that is agreed.

Is this an emergency-response service?

No. Diagnostics are scheduled work. If a system is failing right now, your on-call team or your platform provider's support is the right first contact.

Working for a client? See how agency engagements work.

Have a performance question worth investigating?

Describe the system, the problem, and what you need to find out. We can then establish whether a focused engagement is the right next step.