How to Monitor Database Query Performance: Find and Fix Slow Queries Before They Hurt Your Users

A slow page is rarely a slow page. Most of the time, it is a slow query. Your application can be well-designed, your cache can be warm, and your frontend can be fast — but one missing index or one unoptimized query can turn a 50-millisecond request into a 5-second timeout. Unlike a hard crash, a slow query rarely shows up in an error log. It quietly degrades the experience until users leave.

Monitoring database query performance is different from watching whether your database is up. Both matter, but they answer different questions. This guide walks through the metrics that reveal slow queries, the exact SQL to find them in PostgreSQL and MySQL, and how to keep watch around the clock.

Two Different Questions: Is It Up, and Is It Fast?

Database monitoring splits into two layers. Availability monitoring answers a simple question: can your application still reach the database, and is it responding within a reasonable time? Query performance monitoring answers a harder question: which specific queries are slow, why they are slow, and whether they are getting worse as data grows. You need both — a database can be perfectly reachable while a single runaway query brings your application to its knees.

The Metrics That Actually Matter

Before hunting for slow queries, decide what you are measuring. These numbers separate a healthy database from one about to cause an incident:

• Query latency — how long a query takes to execute, reported as p50, p95, and p99. A p50 of 10 ms with a p99 of 3 seconds means most users are fine but a few are waiting.
• Throughput (QPS) — queries per second. A sudden spike can reveal a new feature or a noisy neighbor on shared infrastructure.
• Slow query rate — the share of queries exceeding your threshold (for example, 500 ms). This is the number that should alert you first.
• Connection pool saturation — when all connections are busy, new requests wait. High wait time is often a symptom of slow queries, not a lack of connections.
• Lock and deadlock events — one long-running transaction can block everything behind it.

Find Slow Queries in PostgreSQL

PostgreSQL has one tool that does most of the work: the pg_stat_statements extension. It records aggregate statistics for every query that runs, including total time, mean time, and the number of calls. Enable it once and you get a permanent leaderboard of your slowest queries.

• Enable the extension: run CREATE EXTENSION IF NOT EXISTS pg_stat_statements;, add it to shared_preload_libraries, then restart the server.
• Rank your slowest queries by mean time: SELECT query, calls, mean_exec_time, max_exec_time FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 10;
• Zoom into a single query with EXPLAIN ANALYZE. It runs the query and shows the plan, so you can see whether it uses an index or performs a full table scan.
• Watch for Seq Scan on a large table, a big gap between estimated and actual rows, and expensive sorts — the three most common causes of slow PostgreSQL queries.

Find Slow Queries in MySQL

MySQL keeps a slow query log that you can enable with a few settings. It captures every query that runs longer than long_query_time, which makes it the fastest way to find your worst offenders without adding a monitoring tool.

• Enable it: SET GLOBAL slow_query_log = 1; SET GLOBAL long_query_time = 1; then locate the file with SHOW VARIABLES LIKE 'slow_query_log_file';
• Inspect a plan with EXPLAIN on any SELECT. Look at the type column — ALL means a full table scan, usually the thing to fix.
• Check index coverage with SHOW INDEX FROM your_table; and look for missing or unused indexes.
• Watch Threads_running and Threads_connected in SHOW STATUS; a rising number of running threads often means slow queries are holding connections open.

Fix the Root Cause, Not the Symptom

Finding a slow query is only half the job. The fixes tend to fall into a few well-known categories:

• Missing index — the most common cause. An index on your WHERE and JOIN columns often turns a full scan into a few milliseconds.
• The N+1 problem — an ORM that runs one query per row instead of one for the whole set. Look for many tiny, nearly identical queries in your logs.
• Over-fetching — selecting columns you never use or rows you do not need. Limit results and select only what you display.
• Connection pool misconfiguration — a pool that is too small queues requests; one that is too large can overwhelm the database. Tune it against real traffic.

Know Before Your Users Do

Query-level tools tell you what is slow inside the database. They do not tell you whether your database is reachable from your application, or whether a health-check query still answers while you sleep. That is where external monitoring comes in.

isthisthing.online lets you create a MySQL or PostgreSQL Monitor that connects to your database on a schedule, runs a check, and measures the Response Time. If the database stops responding or a check exceeds its Timeout, you get an alert through Email, Slack, or your other channels — before your users ever see an error. Combined with an Incident timeline and a public Status Page, you turn "the site got slow" into a message you send instead of one you receive.

A Practical Checklist

• Turn on slow query logging (PostgreSQL: pg_stat_statements; MySQL: slow_query_log).
• Find your top 10 slowest queries and run EXPLAIN ANALYZE on each.
• Fix missing indexes and the N+1 problem first — they give the biggest wins.
• Set a latency threshold and alert on it, not just on errors.
• Add a MySQL or PostgreSQL Monitor in isthisthing.online to watch availability and Response Time from outside.
• Review query metrics after every deployment and every schema change.

Slow queries do not announce themselves. They accumulate until the site feels slow, the database saturates, and you are firefighting an outage you could have prevented. Monitor your database from the inside and the outside, and let isthisthing.online tell you first.

Create your first Monitor today. Open your free account and catch slow queries before your users do.