Your application starts responding sluggishly at 2PM on a Tuesday. The web servers look fine, disk space is healthy, and CPU usage sits at a comfortable 40%. Yet something is clearly wrong.
Fifteen minutes of digging reveals the culprit: MySQL has quietly exhausted its connection pool. Your database is refusing new connections while existing ones hang indefinitely, but none of your monitoring caught it because you're tracking server metrics, not database health.
Essential MySQL Metrics Every Small Team Should Monitor
Most small teams monitor everything except their database. They'll track CPU spikes and disk usage religiously but completely miss connection pool exhaustion, slow query accumulation, and buffer pool thrashing.
Start with these four fundamental metrics that catch 90% of database problems before they impact users:
Connection usage: Monitor Threads_connected against max_connections. If you're consistently above 70% of your connection limit, investigate connection pooling or increase the maximum.
Buffer pool hit ratio: The Innodb_buffer_pool_read_requests versus Innodb_buffer_pool_reads tells you how often MySQL finds data in memory versus disk. Ratios below 95% suggest memory pressure.
Slow query accumulation: Track Slow_queries over time rather than just the absolute number. A sudden increase often signals new problematic queries or parameter changes.
Lock contention: Monitor Table_locks_waited to catch applications fighting over table access. This metric spikes during poorly optimised batch operations.
Query Performance and Slow Query Log Analysis
MySQL's built-in slow query log captures queries exceeding your configured time threshold. Enable it with slow_query_log=1 and set long_query_time=2 to catch queries taking longer than two seconds.
The Performance Schema's sys.user_summary_by_stages view reveals which users and applications consume the most database time. Run SELECT * FROM sys.user_summary_by_stages ORDER BY total_latency DESC LIMIT 10; to identify your heaviest database users.
For real-time analysis, SHOW PROCESSLIST displays active connections and their current queries. Look for queries in 'Sending data' or 'Copying to tmp table' states that persist across multiple checks.
Connection Pool and Thread Monitoring
Connection pool problems manifest long before complete exhaustion. Monitor these patterns:
Rapid connection cycling: High Connections values with low Threads_connected suggests applications aren't reusing connections efficiently.
Thread cache misses: Compare Threads_created to Connections. If they're nearly equal, increase thread_cache_size to reduce connection setup overhead.
Aborted connections: Track Aborted_connects and Aborted_clients to identify network issues or application timeout problems.
Setting Up Lightweight Monitoring with Built-in Tools
Forget enterprise database monitoring platforms that cost more than your entire server budget. MySQL includes everything needed for comprehensive health monitoring.
Configuring MySQL Performance Schema
The Performance Schema collects detailed execution statistics without external dependencies. Enable specific monitoring with:
UPDATE performance_schema.setup_consumers
SET enabled='YES' WHERE name='events_statements_summary_by_digest';
UPDATE performance_schema.setup_instruments
SET enabled='YES' WHERE name LIKE 'statement/sql/%';
This configuration captures query patterns and execution statistics while adding minimal overhead to database operations.
Creating Custom Health Check Scripts
A simple bash script using mysqladmin provides comprehensive health snapshots:
mysqladmin extended-status | grep -E '(Threads_connected|Innodb_buffer_pool_read_requests|Slow_queries|Table_locks_waited)'
Combine this with system metrics from Server Scout's server monitoring to correlate database performance with underlying infrastructure health.
Practical Threshold Examples for Small Team Environments
Generic database monitoring thresholds often trigger false alarms or miss real problems. Small teams need thresholds calibrated to their actual usage patterns.
Memory Usage Warning Levels
Set buffer pool monitoring at 85% memory usage, not arbitrary percentages. Calculate this as: (Innodb_buffer_pool_pages_data / Innodb_buffer_pool_pages_total) * 100. Most small applications work efficiently until buffer pool pressure forces frequent disk reads.
Monitor Created_tmp_disk_tables versus Created_tmp_tables. Ratios above 25% indicate insufficient tmp_table_size or complex queries requiring disk-based temporary storage.
Connection Limit Thresholds
Alert at 70% of max_connections, not 90%. Connection exhaustion happens quickly, and you need time to investigate before complete failure. A web application supporting 50 concurrent users typically needs 100-150 database connections accounting for connection pooling and background processes.
For teams using our knowledge base guidance, correlate connection spikes with web traffic patterns to identify normal versus problematic usage.
Common Performance Bottlenecks System Monitoring Can Catch
Database problems often manifest as system-level symptoms before affecting application metrics. Understanding these patterns helps small teams diagnose issues without deep MySQL expertise.
Disk I/O Saturation Patterns
MySQL I/O problems create distinctive system signatures. Watch for sustained disk queue depths above 10 combined with MySQL's Innodb_data_pending_reads increasing steadily.
Temporary table creation causes I/O spikes when tmp_table_size is exceeded. Monitor /tmp disk usage alongside MySQL's temporary table metrics to catch runaway query optimisation problems.
Lock Contention Detection
Database lock waits appear as CPU context switching spikes without corresponding CPU usage increases. Monitor system load average increases that don't correlate with processor utilisation.
InnoDB deadlocks increment Innodb_deadlocks while creating characteristic patterns in MySQL's error log. Simple log parsing catches these before applications start timing out.
Server Scout's lightweight monitoring approach means you can track both system-level indicators and database-specific metrics without the resource overhead of heavyweight monitoring agents. Our alerting system lets you correlate MySQL connection exhaustion with infrastructure load patterns, providing context that pure database monitoring misses.
Small teams succeed with database monitoring by starting simple, focusing on connection health and query performance, then expanding monitoring as expertise grows. MySQL's built-in tools provide comprehensive visibility without enterprise software complexity or costs.
FAQ
How often should I check MySQL metrics without impacting performance?
Check connection counts and buffer pool statistics every 60 seconds. Slow query logs and detailed Performance Schema analysis can run every 5-10 minutes. These intervals catch problems quickly while adding negligible overhead.
What's the most important single metric for small teams to monitor?
Monitor Threads_connected as a percentage of max_connections. Connection exhaustion causes complete application failures, while most other MySQL problems degrade performance gradually.
Can I monitor multiple MySQL instances effectively without dedicated database tools?
Yes, simple scripting with mysqladmin works across multiple instances. Use SSH key authentication to collect metrics from remote servers, then aggregate results in your monitoring dashboard.