<p>The InnoDB storage engine cannot write an undo log record because the data modification is larger than the allowed size.</p>
<p>MySQL Error 1713: ER_UNDO_RECORD_TOO_BIG occurs when a single INSERT, UPDATE, or DELETE generates an undo log entry that exceeds InnoDB limits. Split the operation into smaller batches or increase innodb_log_file_size to resolve the issue.</p>
Undo log record is too big.
Error 1713 ER_UNDO_RECORD_TOO_BIG appears when InnoDB tries to record a data change in the undo log and the record crosses the maximum allowed size. The engine aborts the statement and returns 'Undo log record is too big', rolling back the transaction.
The limit is roughly 2GB per undo record in recent MySQL versions, but practical limits are lower because the record must fit inside an undo segment page. Large LOB updates or huge multi row statements usually reach this threshold.
Most occurrences come from updating or inserting very large BLOB or TEXT values in a single statement. The before image for the entire column must be stored, inflating the undo record.
Another trigger is a massive UPDATE touching many wide rows, which generates an oversized metadata footprint inside the undo log. Limited undo tablespace capacity can also surface the error sooner.
Break the operation into smaller batches so each individual DML statement produces a smaller undo entry. Chunked updates avoid breaching the limit.
If batch processing is not possible, raise system limits by increasing innodb_log_file_size and innodb_log_buffer_size, then restart MySQL so the new redo and undo capacity takes effect.
Bulk loading media files often fails with error 1713. Load the files row by row or use LOAD_FILE into a staging table and copy in smaller pieces.
Schema migrations that widen VARCHAR to LONGTEXT may hit the error when updating existing rows. Alter the table with ALGORITHM=INPLACE and update rows in limited slices using LIMIT and OFFSET.
Store large object data in external blob storage and only keep pointers in MySQL to prevent oversized undo entries.
Enable application level batching so that no single transaction updates or inserts gigabytes of data. Combine this with monitoring of innodb_undo_log_truncate metrics.
Error 1205 lock wait timeout exceeded appears when large transactions block others. Reducing batch size fixes both issues simultaneously.
Error 1114 table is full can surface when the undo tablespace grows on disk. Freeing disk space or adding undo tablespaces resolves it.
Updating or inserting a single row that contains a multi megabyte BLOB or TEXT column produces an undo entry larger than InnoDB allows.
An UPDATE without a WHERE clause on a table containing wide rows generates a huge before image for every modified row inside one undo record.
Changing compressed data or altering row format may expand the physical row size, unexpectedly inflating the undo payload.
Using default undo tablespace files with limited size leaves no room for large records, triggering the error sooner.
Occurs when a long transaction like the one that triggers 1713 blocks other sessions.
Appears when undo or temporary tables run out of space during large data changes.
Signals that the tablespace, including undo, has no free pages, often linked to the same workload pattern.
No. InnoDB requires undo logging for transactional consistency. Disabling it is not supported.
Staying below a few hundred megabytes per row keeps the undo record well under internal limits on most builds.
It helps but is not guaranteed. If a single row change exceeds 2GB the error still appears. Batching is safer.
Galaxy's AI copilot flags risky bulk updates and suggests batching strategies before you run the query, reducing the chance of error 1713 in production.
.avif)
.avif){kind=logo}
