<p>The server refuses to execute a statement because it would inject row-based events while BINLOG_FORMAT is STATEMENT.</p>
<p>MySQL Error 1666: ER_BINLOG_ROW_INJECTION_AND_STMT_MODE occurs when a statement needs row-based logging but the server is set to STATEMENT mode. Switch BINLOG_FORMAT to ROW or MIXED, or disable the offending feature, to execute successfully.</p>
Cannot execute statement: impossible to write to binary
Error 1666 signals that MySQL cannot record the current statement in the binary log. The operation generates row-based events, yet the server or session is configured for statement-based logging.
The error text is: Cannot execute statement: impossible to write to binary log since statement is in row format and BINLOG_FORMAT = STATEMENT.
The error appears in MySQL 5.6 and later when triggers, foreign key cascades, or Group Replication inject row events while the binlog format is locked to STATEMENT.
It also shows up during online DDL, INSERT ... ON DUPLICATE KEY UPDATE, or other operations that MySQL logs internally as row events.
If the server cannot write to the binary log, replication stops and point-in-time recovery becomes impossible. Production environments relying on replicas or backups face data-loss risk until logging is restored.
The main cause is a mismatch between required row-based logging and an enforced STATEMENT binlog format. MySQL blocks the query to protect replication consistency.
Session-level overrides, restrictive startup options, or unexpected internal row injections can trigger the mismatch.
The quickest fix is to switch the binary log format to ROW or MIXED for the session or globally, then re-run the statement.
Alternatively, disable the feature producing row events, such as a trigger, before executing the statement, then re-enable it.
During Group Replication, use mixed or row format so member nodes can replay row events reliably.
For online ALTER TABLE, set binlog_format='ROW' in the same session to let metadata changes log safely.
Standardize on MIXED or ROW binlog format in production to avoid format conflicts.
Automate environment checks that alert when binlog_format differs from the application requirement.
Errors 1592, 1665, and 1670 also involve binary log issues. They usually resolve after switching to ROW format or disabling unsafe statements.
Triggers and cascades generate row images internally, forcing row-based logging that conflicts with STATEMENT mode.
Group Replication injects row events for conflict detection. STATEMENT mode blocks these writes, leading to error 1666.
DDL features that modify data online emit row events, which cannot be logged in STATEMENT format.
A client may enforce STATEMENT at session level while the workload expects ROW, causing a mismatch.
Occurs when a user lacks the SUPER privilege required for row format changes. Grant or change user permissions.
Raised when a storage engine needs row format but logging is STATEMENT. The fix is identical: switch to ROW.
Triggers when row injection collides with STATEMENT mode at engine level. Resolved by using ROW or MIXED format.
No. The server still relies on the binary log for point-in-time recovery and some online DDL features. Ignoring the error risks data loss.
ROW logging writes more data to the binlog but usually has minimal runtime impact. Compression and faster storage reduce overhead.
In most cases yes. MySQL selects ROW for unsafe statements and STATEMENT for others, reducing conflicts.
Galaxy surfaces server variables in the editor sidebar. You can set binlog_format per tab and share the validated query with teammates to avoid future errors.
.avif)
.avif){kind=logo}
