MySQL and MariaDB I/O shows storage and read/write activity for a monitored server. Use it to diagnose slow disks, heavy write workload, and resource pressure.
Workflow
- Open I/O.
- Review read, write, and latency metrics where available.
- Compare spikes with Activity and Queries.
- Check InnoDB for storage-engine context.
How To Interpret MySQL And MariaDB I/O
I/O evidence shows whether storage activity is part of a performance problem. Heavy reads can come from table scans, poor indexing, reporting workload, or a buffer pool that cannot hold the active data set. Heavy writes can come from normal transaction volume, batch jobs, index maintenance, binary logging, replication, or temporary objects.
Start with timing. Match I/O spikes to application incidents, scheduled jobs, backups, imports, or maintenance. Then use Queries to find statements that drive large reads or writes and InnoDB to check transaction and buffer pool behavior.
If host OS login is configured, operating system storage metrics can add context that database-only metrics cannot provide. See Host OS Login for the metrics granted by Windows or Linux host monitoring.
MySQL And MariaDB I/O FAQ
Does high I/O always mean bad storage?
No. High I/O may be caused by query patterns, missing indexes, normal batch workload, or insufficient cache.
What should I check during write spikes?
Review write-heavy queries, transactions, scheduled jobs, replication/binlog behavior, and disk latency.
Why do I/O metrics vary by platform?
Self-managed servers, cloud databases, containers, and managed services expose different storage counters and permissions.
Next Steps From I/O Evidence
After identifying an I/O spike, match it to the workload that was running at the same time. Check Queries for statements with large reads or writes, InnoDB for engine-level pressure, and Activity for sessions currently doing work. If host metrics are available, compare database activity with operating system disk latency and queue behavior.