<p>The binary log statement cache exceeded max_binlog_stmt_cache_size, so MySQL aborted the multi-row statement and returned error 1705.</p>
<p>MySQL Error 1705: ER_STMT_CACHE_FULL means the binary log statement cache grew beyond the max_binlog_stmt_cache_size setting during a transaction. Increase the variable or rewrite the statement to fit within the limit to resolve the error.</p>
Multi-row statements required more than
MySQL keeps each transactional statement in a per-session binary log cache before writing it to the binary log. When a single multi-row statement outgrows the max_binlog_stmt_cache_size threshold, the server stops execution and returns error 1705 (ER_STMT_CACHE_FULL).
The error protects the server from allocating excessive memory, but it also halts the offending transaction. Production inserts, updates, or deletes that touch many rows are most often affected.
The error appears during transactional statements such as INSERT ... SELECT, bulk UPDATE, or large DELETE that generate more cached data than allowed. It is common on replication masters where binary logging is enabled and the default cache limit remains unchanged.
Because DDL is logged immediately, it rarely causes this error. Only DML statements that accumulate in the statement cache trigger the size check.
If the cache limit is hit, the entire statement rolls back, leaving data unchanged and applications in an inconsistent state. On replication setups, failing statements break consistency between master and replicas, causing lag or stop events.
Addressing the root cause prevents repeated transaction failures, protects data integrity, and maintains replication health.
max_binlog_stmt_cache_size defines the hard cap for the statement cache. binlog_stmt_cache_size controls its initial allocation per session. The global log_bin variable must be ON for the cache to exist.
Adjusting these values or rewriting queries usually resolves the issue quickly.
Galaxy flags long-running or oversized multi-row queries in the editor and suggests rewriting strategies or variable changes before execution, reducing the chance of hitting ER_STMT_CACHE_FULL in production.
Copying millions of rows in a single statement quickly exceeds the default 256MB limit, filling the binary log cache.
Mass updates that touch wide rows generate voluminous before/after images in the cache, triggering the size ceiling.
Tables containing large BLOB or TEXT columns inflate cached data even for moderate row counts.
Systems running with the historical default may simply need a larger limit to accommodate modern workloads.
Similar cache overflow but triggered by binlog_cache_size during a transaction, not max_binlog_stmt_cache_size.
Occurs when a user kills a long-running bulk operation often attempted after repeated cache full errors.
Appears during huge UPDATE or DELETE statements that also risk hitting the statement cache limit.
Large temporary tables from batched inserts can invalidate prepared statements soon after fixing cache issues.
No. The variable must be a positive integer up to 4GB. Setting it too high risks exhausting server memory.
Not always. binlog_stmt_cache_size is the starting size. The error is thrown when the cache grows beyond max_binlog_stmt_cache_size.
Row-based format reduces cache usage but does not eliminate it entirely. Very large batches can still hit the limit.
Yes. MySQL logs ER_STMT_CACHE_FULL with the connection ID, making it easier to trace the failing session.
.avif)
.avif){kind=logo}
