Databases
    Updated May 2026
    MySQL logo

    MySQL Monitoring

    Monitor MySQL InnoDB buffer pool hit ratio, threads connected/running, slow queries, replication lag, and lock waits in real time — via `performance_schema` and `SHOW GLOBAL STATUS`.

    Start Free TrialView Docs

    Why monitor MySQL?

    MySQL powers WordPress, Laravel, Magento, and most LAMP-stack workloads. When buffer pool churn climbs, slow queries pile up, or replication lags, app response time degrades before anyone notices. Per-database monitoring is the difference between a 60-second alert and finding a connection storm in next week's outage post-mortem.

    Auto-discovery via Xitogent — no manual configuration required
    Real-time query throughput and performance metrics
    Track connection pool usage and thread states
    Monitor replication lag and slave status
    InnoDB buffer pool and storage engine metrics
    Slow query detection and monitoring
    Works on both Linux and Windows servers
    1-minute metric collection intervals
    What is MySQL monitoring?

    MySQL monitoring, explained

    MySQL monitoring catches buffer pool churn, slow queries, replication drift, and connection-thread saturation before they slow every read in your app or cascade into a replica failover storm. For WordPress, Laravel, Magento, and any RDS/Aurora-backed workload, per-database visibility is the single most useful signal between user-reported slowness and root cause. Xitoring auto-discovers your MySQL, queries performance_schema and the standard status views, and routes alerts to Slack, PagerDuty, Telegram, or your existing on-call.

    Metrics

    What we monitor

    Threads_connected / Threads_running

    Currently open connections vs threads actively executing queries. Threads_connected near `max_connections` triggers connection refusal; Threads_running spikes indicate query slowdown.

    Queries / sec (Questions)

    Rate of client SQL statements (SELECT, INSERT, UPDATE, DELETE) — derived from the `Questions` counter. Sudden drops signal database hangs or downstream failure.

    InnoDB Buffer Pool Hit Ratio

    Computed as `Innodb_buffer_pool_read_requests / (Innodb_buffer_pool_read_requests + Innodb_buffer_pool_reads)`. Target 99%+; below 95% means you're hitting disk too often — increase `innodb_buffer_pool_size`.

    Innodb_row_lock_waits & lock time

    Number of times InnoDB had to wait for a row lock, plus total wait time in ms. Rising values surface contention from long transactions or hot rows.

    Innodb_deadlocks

    Count of deadlocks detected by the InnoDB monitor. Any non-zero rate is a sign of application transaction-ordering issues — pair with `SHOW ENGINE INNODB STATUS` for the latest deadlock graph.

    Slow_queries / sec

    Rate of queries exceeding `long_query_time` (default 10s). Lower the threshold to 1s and trend the rate — sustained growth means query-plan regression or missing indexes.

    Replication Lag (Seconds_Behind_Source)

    Per-replica delay from primary, via `SHOW REPLICA STATUS`. MySQL 8.0+ provides GTID-based `original_commit_timestamp`/`immediate_commit_timestamp` for precise lag — Xitogent uses both.

    Created_tmp_disk_tables / sec

    Temporary tables that overflowed to disk. Sustained non-zero rate means `tmp_table_size`/`max_heap_table_size` are too small or queries need rewriting.

    Aborted_connects / Aborted_clients

    Failed handshakes vs clients that disconnected ungracefully. Aborted_connects flags auth/network issues; Aborted_clients flags app-side connection leaks or timeouts.

    Bytes_sent / Bytes_received

    Network throughput to and from MySQL. Use alongside Queries/sec to spot result-set bloat (high bytes / low query count) or scan-heavy patterns.

    Open_tables vs table_open_cache

    Currently open table handles vs configured cache size. When Open_tables approaches the cache limit, MySQL evicts and reopens — measurable latency cost.

    Innodb_os_log_pending_fsyncs

    Pending fsyncs to the InnoDB redo log. Sustained non-zero values mean your `sync_binlog`/`innodb_flush_log_at_trx_commit` settings are bottlenecked on disk.

    Triggers & Alerts

    Configurable alert triggers

    Set up custom triggers in your dashboard to get notified the moment MySQL metrics cross your defined thresholds.

    MySQL monitoring trigger configuration dashboard

    Active Connections

    critical

    Fires when active connections approach max_connections, risking new connection refusal and application errors.

    Replication Lag

    critical

    Triggers when replication falls behind, risking data inconsistency between master and replicas.

    Slow Queries

    warning

    Alerts when slow query count exceeds threshold, indicating performance degradation.

    InnoDB Buffer Pool

    warning

    Fires when buffer pool hit ratio drops, indicating excessive disk I/O.

    Aborted Connections

    warning

    Triggers on connection failure spikes, indicating authentication or network issues.

    Table Lock Waits

    critical

    Alerts when lock contention increases, degrading query performance.

    01

    Importance of MySQL Monitoring

    MySQL handles critical data for millions of applications. Without proper monitoring, slow queries, replication drift, and connection exhaustion can lead to outages and data inconsistency.

    • Detect slow queries before they impact user experience
    • Prevent connection pool exhaustion with threshold alerts
    • Monitor replication for data consistency across replicas
    • Track InnoDB performance for optimal storage engine health
    • Identify lock contention and query bottlenecks early
    MySQL monitoring dashboard with query metrics
    Database performance alert timeline
    02

    Why Choose Xitoring

    Xitoring delivers enterprise-grade MySQL monitoring with zero-config setup. Our lightweight agent auto-discovers your MySQL instances, starts collecting metrics in under 60 seconds, and integrates with your existing notification channels.

    • One-command install — no complex YAML or config files
    • 15+ global monitoring nodes for low-latency checks
    • Unified dashboard for servers, databases, and uptime
    • Flexible alerting via Slack, PagerDuty, Telegram & more
    • Historical data retention for capacity planning & audits
    Xitoring multi-database monitoring overview
    Notification channels and alert configuration
    Use cases

    Common MySQL monitoring scenarios

    Where MySQL typically runs today — and what could go wrong if no one's watching.

    Managed cloud database (AWS, Azure, Google)

    Cloud providers handle the servers, but they don't tell you when your own queries are slow, your connections are running out, or a backup copy is quietly falling behind. We catch the issues the provider leaves to you, so a slowdown doesn't catch the team off guard.

    Main database with live backup copies

    Production databases typically run a live backup ready to take over if the main one fails. When that backup quietly falls behind, what should be a smooth handoff becomes a real outage — sometimes with data loss. We watch every copy so the backup is truly ready when you need it.

    Database running inside Kubernetes

    Databases in Kubernetes get moved, restarted, and updated by the platform automatically. Most of the time it's safe — when it isn't, you usually find out from frustrated users. We surface the early warning signs so the team can step in before a routine update becomes an incident.

    Before you start

    Prerequisites for MySQL

    Make sure you've got these in place — most installs are a 60-second job once they are.

    • MySQL 5.7, 8.0, or 8.4 LTS running on the server
    • performance_schema = ON (default in 5.7+; set in [mysqld] if disabled)
    • A monitoring user with PROCESS, REPLICATION CLIENT, and SELECT on performance_schema (recommend MAX_USER_CONNECTIONS 5 cap)
    Setup Guide

    Get started in minutes

    1

    Install Xitogent on your server

    If you haven't already, install the lightweight Xitogent monitoring agent on your server.

    curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEY
    2

    Create a monitoring user in MySQL

    Create a dedicated read-only user for Xitogent to collect metrics:

    CREATE USER 'xitoring'@'%' IDENTIFIED BY 'your_secure_password'; GRANT REPLICATION CLIENT ON *.* TO 'xitoring'@'%' WITH MAX_USER_CONNECTIONS 5; GRANT PROCESS ON *.* TO 'xitoring'@'%'; GRANT SELECT ON performance_schema.* TO 'xitoring'@'%'; FLUSH PRIVILEGES;
    3

    Enable the MySQL integration

    Use the Xitoring dashboard or CLI to enable the MySQL integration with the monitoring credentials.

    sudo xitogent integrate
    4

    Configure alert thresholds (optional)

    Set custom thresholds for metrics like replication lag, slow queries, or connection count to get notified when something needs attention.

    5

    Verify it's working

    Run this command on the server to confirm Xitogent picked up the integration. Fresh metrics will start streaming to your dashboard within ~30 seconds.

    sudo xitogent status
    Compare

    Considering alternatives?

    See how Xitoring stacks up against the alternatives for MySQL monitoring — flat pricing, deeper integrations, and one agent that covers your whole stack.

    See all comparisons

    Frequently asked questions

    What is MySQL monitoring?
    MySQL monitoring is the continuous collection of database performance data from `performance_schema`, the `sys` schema, and `SHOW GLOBAL STATUS` — threads connected/running, query throughput, InnoDB buffer pool hit ratio, row lock waits, deadlocks, slow queries, replication lag, temp tables on disk, and aborted connections — combined with alerting when those metrics breach thresholds. It's how teams catch index regressions, deadlock storms, and replica drift before they cause user-visible slowness.
    How do I monitor MySQL InnoDB buffer pool hit ratio?
    Computed from `SHOW GLOBAL STATUS`: `Innodb_buffer_pool_read_requests / (Innodb_buffer_pool_read_requests + Innodb_buffer_pool_reads) * 100`. Target 99%+ on OLTP workloads — below 95% means hot data isn't fitting in the buffer pool. Fix by raising `innodb_buffer_pool_size` (rule of thumb: 70–80% of system RAM on dedicated MySQL hosts).
    How do I detect slow queries in MySQL?
    Two approaches: enable the slow query log (`slow_query_log = 1`, `long_query_time = 1`, `log_queries_not_using_indexes = 1`) and analyze with `pt-query-digest` from Percona Toolkit; OR query `performance_schema.events_statements_summary_by_digest` for aggregated query metrics. Xitogent surfaces both — slow query count from `Slow_queries` and per-digest mean execution time from `performance_schema`.
    How do I monitor MySQL replication lag?
    Run `SHOW REPLICA STATUS` (MySQL 8.0+) or `SHOW SLAVE STATUS` (legacy) on the replica. `Seconds_Behind_Source` gives the classic timer-based lag; GTID-based `original_commit_timestamp` and `immediate_commit_timestamp` (8.0+) give precise primary-to-replica delay. Xitogent surfaces both per replica and alerts when lag exceeds your RPO budget.
    What is performance_schema and how do I use it?
    `performance_schema` is MySQL's built-in instrumentation engine (enabled by default since 5.6.6). It exposes detailed runtime metrics — statement digests, table/index I/O, wait events, memory allocations, replication state — via standard SQL queries. Xitogent reads it for query-level metrics, lock wait analysis, and connection thread state. The overhead is negligible (~5% on high-throughput workloads, much less on typical apps).
    How do I monitor MySQL on RDS or Aurora?
    Run Xitogent on an EC2 instance with network access to the RDS/Aurora endpoint. Create a monitoring user (`CREATE USER 'xitogent'@'%' IDENTIFIED BY '...'; GRANT PROCESS, REPLICATION CLIENT, SELECT ON performance_schema.* TO 'xitogent'@'%';`) and point Xitogent at the endpoint. CloudWatch covers the AWS-instance metrics; Xitogent covers everything inside MySQL.
    What's the difference between MySQL and MariaDB monitoring?
    The core engine vocabulary (`Threads_connected`, `Innodb_buffer_pool_*`, `Slow_queries`, etc.) is shared. MariaDB diverges in: (1) Galera cluster monitoring uses the `wsrep_*` namespace (cluster size, flow control, donor/joiner state) — completely absent from vanilla MySQL; (2) tools like MariaDB MaxScale and ClusterControl; (3) ColumnStore and Spider engines; (4) replication GTID format differs. Use this MySQL integration for MySQL/RDS/Aurora; use the dedicated MariaDB integration for MariaDB and Galera clusters.
    Will this integration affect MySQL performance?
    No measurable impact. Xitogent uses lightweight, read-only queries against `performance_schema` and `SHOW GLOBAL STATUS` — the same mechanism MySQL's own tools use. The monitoring user is capped with `MAX_USER_CONNECTIONS 5` so the agent can never exhaust the connection pool. Polling at 60-second intervals adds negligible CPU load.
    What MySQL versions are supported?
    MySQL 5.7, MySQL 8.0 (sunset approaching), MySQL 8.4 LTS (current), and the 9.x innovation track. The integration auto-detects whether `SHOW REPLICA STATUS` (8.0+) or `SHOW SLAVE STATUS` (legacy) is the right call, and which `performance_schema` tables are present. For MariaDB or Galera clusters, use the dedicated MariaDB integration instead.

    Start monitoring MySQL today

    Set up in under 60 seconds. No credit card required. Full metrics from day one.

    Start Free Trial

    Keep exploring

    Related Integrations