Slow Query Log Analyzer

A slow query log is almost never a list of different problems: it is the same handful of statements repeated with different literals. This analyzer reads a MySQL or MariaDB slow query log, a PostgreSQL log written by log_min_duration_statement, or a plain list of statements, replaces every literal with a placeholder so that executions of the same statement collapse into one shape, and ranks those shapes by the total time they consumed. For each shape you get call count, average, minimum and maximum duration, the rows examined to rows sent ratio that exposes missing indexes, lock wait share, and a sample of the original statement, plus follow-up SQL for EXPLAIN ANALYZE, pg_stat_statements and performance_schema. Parsing happens entirely in your browser; the log never leaves the page.

Log formatRank byShowMin duration (ms)

Slow query log

# Time: 2026-09-12T08:14:02.118231Z
# User@Host: app[app] @ 10.0.3.14 []  Id: 90412
# Query_time: 4.812355  Lock_time: 0.000181 Rows_sent: 25  Rows_examined: 2841193
SET timestamp=1757664842;
SELECT o.id, o.total, c.email FROM orders o JOIN customers c ON c.id = o.customer_id WHERE o.status = 'pending' AND o.created_at >= '2026-09-01' ORDER BY o.created_at DESC LIMIT 25;
# Time: 2026-09-12T08:14:07.554120Z
# User@Host: app[app] @ 10.0.3.15 []  Id: 90418
# Query_time: 3.907712  Lock_time: 0.000094 Rows_sent: 25  Rows_examined: 2840117
SET timestamp=1757664847;
SELECT o.id, o.total, c.email FROM orders o JOIN customers c ON c.id = o.customer_id WHERE o.status = 'paid' AND o.created_at >= '2026-08-15' ORDER BY o.created_at DESC LIMIT 25;
# Time: 2026-09-12T08:15:31.002744Z
# User@Host: report[report] @ localhost []  Id: 90501
# Query_time: 12.440918  Lock_time: 0.000210 Rows_sent: 1  Rows_examined: 8912440
SELECT count(*) FROM events WHERE payload LIKE '%checkout_failed%';
# Time: 2026-09-12T08:16:44.881003Z
# User@Host: app[app] @ 10.0.3.14 []  Id: 90544
# Query_time: 0.918440  Lock_time: 0.000102 Rows_sent: 1  Rows_examined: 1
SELECT * FROM users WHERE email = 'ada@example.com';
# Time: 2026-09-12T08:17:02.410911Z
# User@Host: app[app] @ 10.0.3.16 []  Id: 90560
# Query_time: 1.220118  Lock_time: 0.000099 Rows_sent: 1  Rows_examined: 1
SELECT * FROM users WHERE email = 'grace@example.com';

Summary

Parsed as: MySQL / MariaDB slow query log (auto-detected)
Statements parsed: 5
Distinct query shapes: 3
Total time in the log: 23.300s across 5 executions (mean 4.660s)
Log window: 2026-09-12T08:14:02.118231Z .. 2026-09-12T08:17:02.410911Z
The top 3 shapes account for 100% of the total time.

Ranked query shapes

#1  12.441s total  (53% of log)
    calls 1   avg 12.441s   min 12.441s   max 12.441s
    rows examined 8,912,440   rows sent 1   ratio 8912440:1
    lock time 0.2ms

    shape:  SELECT count(*) FROM events WHERE payload LIKE ?

    sample: SELECT count(*) FROM events WHERE payload LIKE '%checkout_failed%'

    - Examines 8,912,440 rows per execution to return 1, a ratio of 8912440:1 - the usual sign of a missing or unusable index on the WHERE/JOIN columns.
    - Leading-wildcard LIKE '%...%' cannot use a B-tree index; consider a full-text index, a trigram index (Postgres pg_trgm) or a dedicated search column.

------------------------------------------------------------------------------

#2  8.720s total  (37% of log)
    calls 2   avg 4.360s   min 3.908s   max 4.812s
    rows examined 5,681,310   rows sent 50   ratio 113626:1
    lock time 0.3ms

    shape:  SELECT o.id, o.total, c.email FROM orders o JOIN customers c ON c.id = o.customer_id WHERE o.status = ? AND o.created_at >= ? ORDER BY o.created_at DESC LIMIT ?

    sample: SELECT o.id, o.total, c.email FROM orders o JOIN customers c ON c.id = o.customer_id WHERE o.status = 'pending' AND o.created_at >= '2026-09-01' ORDER BY o.created_at DESC LIMIT 25

    - Examines 2,840,655 rows per execution to return 25, a ratio of 113626:1 - the usual sign of a missing or unusable index on the WHERE/JOIN columns.
    - ORDER BY with LIMIT is fast only when an index already provides the sort order; check that the ORDER BY columns are a prefix of an index that also covers the WHERE clause.

------------------------------------------------------------------------------

#3  2.139s total  (9% of log)
    calls 2   avg 1.069s   min 918.4ms   max 1.220s
    rows examined 2   rows sent 2   ratio 1:1
    lock time 0.2ms

    shape:  SELECT * FROM users WHERE email = ?

    sample: SELECT * FROM users WHERE email = 'ada@example.com'

    - SELECT * prevents index-only scans and moves columns you do not read; list the columns you need.

Follow-up SQL

-- 1. Get the plan for the worst shape (replace ? with realistic values, not NULLs)
--    MySQL 8:
EXPLAIN ANALYZE SELECT count(*) FROM events WHERE payload LIKE '%checkout_failed%';

--    PostgreSQL:
EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT) <the same statement>;

-- 2. Confirm the ranking against the server counters instead of one log window
--    PostgreSQL (needs the pg_stat_statements extension):
SELECT queryid, calls, round(total_exec_time) AS total_ms,
       round(mean_exec_time) AS mean_ms, rows, query
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 20;

--    MySQL 8 (performance_schema, already normalised by digest):
SELECT digest_text, count_star AS calls,
       round(sum_timer_wait/1e12, 3) AS total_s,
       round(avg_timer_wait/1e9, 3)  AS avg_ms,
       sum_rows_examined, sum_rows_sent
FROM performance_schema.events_statements_summary_by_digest
ORDER BY sum_timer_wait DESC
LIMIT 20;

-- 3. Make sure the log keeps catching the right queries
--    MySQL:
SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 1;              -- seconds
SET GLOBAL log_queries_not_using_indexes = ON;

--    PostgreSQL (postgresql.conf, then SELECT pg_reload_conf()):
-- log_min_duration_statement = 1000         # ms, -1 disables
-- log_line_prefix = '%m [%p] %u@%d '
-- auto_explain.log_min_duration = 1000      # with shared_preload_libraries = 'auto_explain'

Do more than slow query log analyzer — meet Chat2DB

Chat2DB is an AI-powered SQL client for Windows, macOS and Linux. Write SQL in natural language, format and optimize queries automatically, and manage MySQL, PostgreSQL, Oracle and 20+ other databases in one workspace.

How to use

Paste the contents of your slow query log, or a section of it, into the log box. Leave the format on Auto-detect unless the log has an unusual prefix.
Sort by total time to find the query that costs the most wall clock overall, or by rows examined to find the ones scanning the most data, and raise the minimum duration to drop noise.
Take the top shape into EXPLAIN ANALYZE using the generated follow-up SQL, then confirm the ranking with pg_stat_statements or performance_schema before you add an index.

Frequently asked questions

Why group queries by shape instead of reading the log line by line?

Because ranking raw log lines answers the wrong question. A report that runs once and takes 12 seconds looks worse than a query that takes 80 milliseconds, but if that second query runs 40,000 times an hour it is consuming far more of the server. Replacing literals with placeholders turns both into a single row each, so you can compare them on total time, which is the number that predicts how much load you remove by fixing one of them. This is the same normalisation that pg_stat_statements does with queryid and that MySQL performance_schema does with digest_text; doing it in the browser just lets you apply it to a log file you already have, including logs from servers where those features are not enabled.

What does a high rows examined to rows sent ratio mean?

It means the server read a large number of rows to produce a small result, which is the clearest signal a log can give that an index is missing or unusable. If a query examines 2.8 million rows and sends 25, the engine scanned a table or a large index range and threw almost everything away. Common causes are a WHERE column with no index, a leading-wildcard LIKE, a function wrapped around an indexed column such as DATE(created_at) = ..., an implicit type conversion between a string column and a numeric literal, or an ORDER BY that cannot use the same index as the WHERE clause. Postgres logs do not include the row counters, so the ratio only appears for MySQL and MariaDB logs; for Postgres use EXPLAIN (ANALYZE, BUFFERS) and compare the estimated and actual row counts instead.

Is my slow query log uploaded anywhere?

No. The parsing, normalisation and aggregation all run as JavaScript in this page, so the text you paste stays in the browser tab and is discarded when you close it. That matters because slow query logs contain production literals, including email addresses, identifiers and sometimes tokens embedded in WHERE clauses. If you want to go from the ranked list to the actual database, Chat2DB can connect to MySQL, PostgreSQL and other engines to run EXPLAIN, inspect indexes and test a fix: download it at https://chat2db.ai/download or use the web version at https://app.chat2db.ai.