For an engineering manager: turn a slow, flaky service into measured data-layer items

Start with a baseline, not a theory

When a service is slow, each engineer has a favourite cause: the missing index, the small pool, the cache. A baseline replaces opinion. Make sure statement statistics (PostgreSQL) or the slow query log (MySQL) have been collecting from real traffic, with the threshold low enough to catch what users feel; the MySQL default of ten seconds will not. Take the top statements by total time, the query count for your slowest endpoints on a copy, and the connection counts by state at the busy hour.

Write those figures down with the date and engine versions. They are what you will compare against after any change, and what a specialist will ask for first.

• Statement statistics or slow log running across a full business cycle.
• Query counts per request for the three slowest endpoints.
• Connections by state at the busiest hour.

Pick the smallest set of bounded jobs

Match the baseline to the job. A repeating statement and a count that grows with the list is the one-endpoint query-count job. One dominant statement is the slow-query job. Many slow statements or unaccounted-for indexes is the index review. Pool timeouts with idle-in-transaction connections is the connection job. Each is priced as an untested proposal and accepted by a before and after measurement you can repeat.

If several apply to the same service, the data-layer project lists them as one agreed set, fixed price for the list, with an opening and a closing measurement under the same load profile. Do not start with the project if one job explains the whole baseline.

• One cause: one job. Several causes: one project.
• Ask for the acceptance test before the work, not after.

What to settle on your side first

Three things need an owner before anyone measures. A staging copy of realistic size with personal data removed or replaced. A restore point that has actually been restored; no change to production data should be scheduled without one. And a person who can accept each item and apply changes under your release process. The work is done on the staging copy and returned as pull requests or scripts; nothing is applied to production by an outside party.

If you lack the restore point, that comes first, and the off-site backup and restore-test job exists for a website database.

• Name the accepter and the person who applies changes.
• Agree the lock-wait and downtime limits in writing.

Start with a low-trust enquiry

Send the engine and framework versions, the symptoms in plain words, how long statistics have been collecting, and the baseline figures with literal values removed. Do not send credentials, code, dumps or real rows. An enquiry books nothing and charges nothing; scope and price are agreed in writing, and payment follows the agreed checks and your sign-off.

This page is a buyer hypothesis. It is not evidence that managers have asked for these jobs or that any has been delivered.