Three Surprising Ways to Crash MySQL (And How to Prevent Them)

1. Flooding Undo Logs

InnoDB uses undo logs to support MVCC. If a transaction repeatedly updates a row without committing, undo logs accumulate, eventually filling the disk and rendering MySQL unusable because the logs cannot be reclaimed.

The current InnoDB implementation imposes no per‑connection limit on undo space, so a single long‑running transaction can exhaust disk space. The test requires only UPDATE privileges.

During the test, disk usage continuously rises until it is full, after which any further SQL statements fail with errors such as "No space left on device" and MySQL logs show the process still running but the service unavailable.

To avoid this, keep transactions small and monitor undo and binlog growth, especially on production systems.

2. Defining Massive User Variables

Creating a large number of user‑defined variables consumes MySQL memory rapidly, eventually causing the operating system to kill the MySQL process. This method only requires login privileges, not write access.

Memory usage can be observed with pidstat, showing a steady increase until the process disappears. The kernel log ( dmesg) confirms the kill was due to out‑of‑memory.

MySQL allows resource limits per user, such as maximum queries, updates, connections per hour, and concurrent connections. Setting these limits can mitigate abuse:

Maximum queries per hour

Maximum updates per hour

Maximum connections per hour

Maximum concurrent connections

Configuration can be applied via GRANT ... WITH MAX_QUERIES_PER_HOUR ... (see screenshot).

In practice, many administrators are unaware of these limits, leaving databases vulnerable to malicious or careless users.

3. Triggering a MySQL Bug

Even mature databases contain bugs. One reproducible bug occurs when granting privileges using an excessively long database name, causing MySQL 5.6.19 to crash instantly while the same operation works in MySQL 5.7 (bug fixed).

This is a classic buffer‑overflow issue; upgrading to a version where the bug is patched prevents the crash.

Conclusion and Recommendations

The three methods illustrate different failure modes: disk exhaustion via undo logs, memory exhaustion via user variables, and software bugs. MySQL is robust in production but can be taken down by mis‑use or unpatched bugs.

Key recommendations:

Avoid extremely large transactions that may fill disk space.

Enforce per‑user resource limits to prevent memory abuse.

Stay updated with MySQL releases and monitor community bug reports.

Be cautious when enabling new features, as they may introduce regressions.