At a glance
The percentage of the data volume the MySQL instance is allowed to use that is currently consumed. For a DBA, this is the single most consequential capacity gauge, because when a MySQL data volume fills completely the server cannot write: transactions fail, the instance can crash, and on some managed services it is forced into read-only or storage-full state. Below 75% is comfortable, 75 to 90% is “plan an expansion”, and above 90% is the alert: you have limited runway before writes stop. Unlike CPU or memory pressure, a full disk does not degrade gracefully; it stops the database hard.
Calculation
The headline is a straightforward ratio of consumed to available capacity on the volume that holds the data directory:DATA_LENGTH + INDEX_LENGTH across information_schema.TABLES, though that excludes logs and free-but-unreclaimed tablespace pages, so it always reads lower than the filesystem figure.
Worked example
A platform team runs a self-managed MySQL 8.0 primary on a 500 GB data volume. On 16 Apr 26 at 03:40 BST the gauge crosses 92%, tripping the> 90% alert in the small hours. The drill-down breaks down the 460 GB consumed:
The data files are not the problem; the binary logs are. The fill-rate projection reads days-to-full: 3.1, which is what makes a 03:40 alert worth acting on rather than deferring.
SHOW REPLICA STATUS on each replica shows the file each is reading, and mysqlbinlog positions confirm none lags behind the purge point): reset the expiry to 3 days and run PURGE BINARY LOGS BEFORE NOW() - INTERVAL 3 DAY;. Roughly 140 GB frees instantly, the gauge drops to around 64%, and the days-to-full projection jumps back to comfortable. The longer-term action is to alert on the expiry setting itself so a test config never silently persists again.
Three takeaways:
- A full data disk is a hard stop, not a slowdown. Every other capacity metric degrades gracefully; this one does not. At 100% MySQL cannot write, transactions fail, and the instance may crash or go read-only. That is why the alert sits at 90%, leaving runway to act.
- Read the breakdown before adding storage. Reflexively growing the volume “fixes” the gauge but hides the cause. Here the answer was a misconfigured binlog expiry, not genuine data growth; adding 200 GB would have masked it for a month and then alerted again.
- Days-to-full beats the raw percentage. 92% with a 0.5 GB/day fill rate is weeks of runway; 92% with a 50 GB/day rate is hours. Always read the projection, not just the gauge, to decide how urgently to act.
Sibling cards to reference together
Reconciling against the source
Where to look in MySQL’s own tooling:For the data portion, sum table sizes:Why our number may legitimately differ from a table-size sum:SELECT table_schema, ROUND(SUM(data_length + index_length)/1024/1024/1024, 2) AS gb FROM information_schema.TABLES GROUP BY table_schema ORDER BY gb DESC;. This excludes logs and unreclaimed free pages, so it reads lower than the filesystem. For binary logs:SHOW BINARY LOGS;lists every binlog file and its size; sum the bytes to see the log footprint. For the true volume figure on self-managed hosts, check the OS:df -h $(mysql -Nse "SELECT @@datadir")shows used and available on the actual mount, which is what the card reports.SELECT @@innodb_data_file_path;andSELECT @@datadir;confirm where the tablespaces and data directory live.
Managed-service cross-checks:
Known limitations / FAQs
My table sizes add up to far less than the card shows. Is the card wrong? Almost certainly not.information_schema.TABLES counts only table and index data. The card measures the whole data volume, which also holds binary logs, redo and undo logs, temporary files, and any slow/general logs on the same mount. On a write-heavy instance binary logs alone can be a large fraction of the volume. Run SHOW BINARY LOGS; and check the log directory before assuming a discrepancy is an error.
I deleted millions of rows but the percentage barely moved. Why?
InnoDB does not return freed space to the operating system when you delete rows; it marks the pages reusable inside the tablespace. The filesystem (and therefore this card) still counts that space as used until you reclaim it with OPTIMIZE TABLE (which rebuilds the table) or a dump-and-reload. Be aware that OPTIMIZE TABLE temporarily needs roughly as much free space as the table itself, so it can be impossible to run when you are already near full. Free up binary logs first to create headroom.
The gauge is at 92%, how long do I actually have?
Read the days-to-full projection in the drill-down, not the percentage. The projection divides remaining space by the recent average fill rate. 92% with slow growth is weeks; 92% with a runaway binlog or a long transaction bloating the undo log is hours. The projection is the number that tells you whether this is a tonight problem or a this-quarter problem.
What actually happens when MySQL hits 100% disk?
It cannot write. New transactions fail, INSERT/UPDATE/DELETE error out, and depending on the build and platform the instance may crash or InnoDB may go into a protective read-only state. On RDS the instance can enter a storage-full state requiring a (possibly disruptive) storage scaling. This hard-stop behaviour is precisely why the alert is set well below 100%, at 90%, to leave runway to act.
Why is my Aurora disk percentage falling when I have not deleted anything?
Aurora storage auto-scales: the cluster volume grows in steps as it fills. When it steps up, the used figure is now a smaller fraction of a larger allocation, so the percentage drops even though absolute usage rose. On Aurora, treat this card as a growth-rate signal (is consumption accelerating?) rather than an imminent-stop warning, because Aurora will keep adding capacity up to its hard ceiling.
Can a single long-running transaction fill the disk?
Yes, indirectly. A transaction held open for a long time prevents InnoDB from purging old row versions, so the undo log and history list grow without bound. On a busy instance this can consume significant space surprisingly fast. If disk is climbing with no obvious data or log growth, check SELECT * FROM information_schema.INNODB_TRX ORDER BY trx_started; for an ancient open transaction and end it.
Does this include space used by binary logs on a replica that has fallen behind?
On the primary, yes: a lagging replica is the most common reason binary logs cannot be purged and pile up. The primary must keep every binlog until all replicas have read it. If Replication Lag is high, the disk problem on the primary is downstream of the lag, so fix the replica before purging logs, and never purge logs a replica still needs.
Can I change the 90% threshold?
Yes. The > 90% trigger is the default alert threshold. A large volume with a slow, predictable fill rate might tolerate alerting at 95%; a small volume with bursty growth might warrant 80% to leave more reaction time. Set it per profile in the Alert Rules tab, ideally informed by your typical fill rate so the alert gives you enough runway to provision or purge before writes are at risk.