Can I undo TRUNCATE in MySQL?

If it ran in a transaction that isn't committed yet, run ROLLBACK. Once committed, you can only recover from a backup, a database log (PITR / binlog / WAL), or a managed-host snapshot — covered step by step above.

An AI agent (Cursor / Claude Code) ran it — does that change anything?

No. The recovery is identical regardless of who ran the query. What matters is whether the change was committed and whether you have a backup or log from before it. Agents do make this far more likely, which is why an automatic snapshot tool is worth setting up.

How do I stop this happening again?

Keep automatic, recent snapshots. OopsDB snapshots your MySQL every few minutes and restores in one command, so a destructive query becomes a quick rollback. It's free and runs locally.

Recovering from `TRUNCATE` in MySQL

Whether you typed it yourself or your AI agent did, here's exactly what to do after a TRUNCATE hit your MySQL / MariaDB — best options first, honest about the rest.

First, in the next 60 seconds

1. Stop all writes. Quit the app, pause the agent, and don't run another query — every write reduces what you can recover.
2. Don't restart, vacuum, or checkpoint the database. Those steps can permanently overwrite recoverable data.
3. Make a copy of the current state now (a dump, a snapshot, or the raw file) before you attempt anything.

What just happened

TRUNCATE empties a table fast by deallocating its pages rather than deleting rows one by one. It usually auto-commits and is not logged per-row, which makes it harder to recover than a DELETE — log-based recovery is your main hope.

Your recovery options in MySQL, best first

1
Roll back an open transaction
On InnoDB, if you have not committed yet, ROLLBACK; undoes it. Note: TRUNCATE and most DDL (DROP) auto-commit, so rollback will not help there.
2
Binary-log point-in-time recovery
If binary logging is on, replay the binlog with mysqlbinlog from your last full backup up to the position/time just before the bad statement, then stop. This rebuilds the data minus the destructive event.
3
Restore from mysqldump
Restore your latest mysqldump into a scratch database and copy the affected table or rows back into production.
4
Check managed-host snapshots
RDS / Aurora / Cloud SQL / PlanetScale keep automated backups and often PITR. Restore to a new instance from the console and copy the data over.

If you have no backup

Without an open transaction, binary logs or a dump, a committed MySQL change cannot be undone by the engine. Undelete-style recovery from the raw InnoDB files is specialist, paid, and unreliable — assume the data is gone and focus on prevention.

Make sure this never happens again

The honest truth: your coding agent will eventually run TRUNCATE again. The fix isn't to trust it more — it's to keep an automatic, recent snapshot so a bad query is a 30-second rollback instead of a lost weekend.

OopsDB takes an encrypted snapshot of your MySQL / MariaDB every few minutes and restores it with one command. It's free, open-source, and runs entirely on your machine — set it up in two minutes and the next TRUNCATE won't cost you anything.

See how it works

Free & open-source for local backups · optional €8/mo cloud vault keeps a copy off your machine · cancel anytime.

Related recovery guides

Recover from DROP TABLE in MySQL Recover from DELETE without WHERE in MySQL Recover from DROP DATABASE in MySQL TRUNCATE in Postgres TRUNCATE in Supabase TRUNCATE in SQLite TRUNCATE in Neon Cursor deleted my database

Recovering from TRUNCATE in MySQL

First, in the next 60 seconds

What just happened

Your recovery options in MySQL, best first

Roll back an open transaction

Binary-log point-in-time recovery

Restore from mysqldump

Check managed-host snapshots

If you have no backup

Make sure this never happens again

Related recovery guides

Recovering from `TRUNCATE` in MySQL