Diting Labs
Talk to us

Slow SQL and the request behind it

Slow SQL tied to services, traces and user replay. The DBA sees the scene, not a screenshot.

A SQL problem is rarely only in the SQL

The same statement behaves differently at different times and with different parameters. Database-internal statistics alone rarely show which request made it slow.

Diting puts the statement back into the request: which service called it, with what parameters, and what the user was doing.

Statement, request, user

  1. Find the statement

    Sort by duration, count or rows returned.

  2. Read the plan

    Plan, indexes, rows scanned.

  3. Find the caller

    The statement belongs to a service and endpoint.

  4. See the user

    Linked session and replay show the interaction.

SQL to sessionDiting
01Slow statementSELECT … WHERE order_id = ?
02Servicecheckout / orders
03User session
Statement, request and user, connected.

DBAs and developers see the same request

Screenshots, log exports and reproduction are unnecessary. Send the link; it opens that page.

  • Top SQL
  • Execution plans
  • Slow query alerts
  • Session replay

Fits

  • Existing systems where connection strings and drivers cannot change
  • Teams that need SQL tied to business context

Doesn't fit

  • Environments that need internal lock-wait detail with Performance Schema disabled

Bring your system in

Tell us what you run: OS, kernel, public network or not, virtual machines or clusters. We will map the path in.

Talk about your estateRead the docs