<p>The server refuses to execute a statement because BINLOG_FORMAT=STATEMENT while at least one referenced table requires row-based logging, blocking binary log writes.</p>
<p>MySQL Error 1665 ER_BINLOG_STMT_MODE_AND_ROW_ENGINE occurs when you run a statement under BINLOG_FORMAT=STATEMENT against a table that can only be logged in ROW mode. Switch to MIXED or ROW binlog format, or change the table’s storage engine to resolve the issue.</p>
Cannot execute statement: impossible to write to binary
The error message “Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging” means MySQL cannot safely record the statement in the binary log.
Binary logging guarantees replication integrity. When BINLOG_FORMAT is STATEMENT, MySQL logs the SQL text. Some storage engines, temporary tables, or special columns only support row-based logging. When such a table is touched while STATEMENT mode is active, the server stops and raises error 1665.
The primary trigger is running with global or session BINLOG_FORMAT=STATEMENT while referencing a table that is flagged for row-based logging only, such as NDB, MEMORY with certain features, or a table containing TIMESTAMP columns with DEFAULT CURRENT_TIMESTAMP in older versions.
User-level SET commands, replication filters, or application frameworks that force STATEMENT logging can surface the error during normal DML operations.
Switch the logging format to MIXED or ROW before executing the statement. This lets MySQL decide per statement or forces row images, satisfying the engine requirement.
Alternatively, migrate the problematic table to a STATEMENT-compatible engine like InnoDB. In edge cases, you can temporarily disable binary logging in the session if replication consistency is not needed.
Bulk inserts into an NDB table fail on STATEMENT format. Solution: SET SESSION binlog_format='ROW' before the transaction.
A migration script sets STATEMENT mode for speed but also touches a MEMORY table with auto-updated timestamps. Switch to MIXED, or split the script into two transactions with different formats.
Keep servers on MIXED binlog format by default. It provides STATEMENT advantages while automatically falling back to ROW when required.
Standardize on InnoDB for transactional tables unless a specific engine is mandatory. Document any row-only engines so developers know to adjust binlog settings.
Error 1660 (ER_BINLOG_ROW_ENGINE_AND_STMT_ENGINE): Opposite mismatch when BINLOG_FORMAT=ROW and a statement-only engine is used. Fix by switching to STATEMENT or MIXED.
Error 1792 (ER_BINLOG_FORMAT_TOO_SMALL): Server refuses ROW-based event because slave version is too old. Upgrade replicas or set binlog_row_format=MINIMAL.
Engines like NDB Cluster, ARCHIVE, or certain MEMORY configurations can be logged only in ROW mode, triggering the mismatch.
Applications that issue SET SESSION binlog_format='STATEMENT' for performance forget to reset it, leading to replication failures.
Tables containing unsafe constructs for STATEMENT logging, such as non-deterministic functions or ON UPDATE CURRENT_TIMESTAMP in old MySQL versions, can cause the error.
Raised when BINLOG_FORMAT=ROW but a statement-only engine is used. Switch formats or engines.
Occurs when row events cannot be applied on older replica versions. Upgrade or adjust row format settings.
No. Ignoring it breaks replication consistency because the statement will not be logged. Fix the binlog format mismatch instead.
Yes. MySQL automatically chooses STATEMENT when deterministic and ROW when required, preventing error 1665 while minimizing log size.
NDB, ARCHIVE, BLACKHOLE, and some MEMORY tables. Additionally, tables using spatial data or non-deterministic defaults may need ROW.
Galaxy surfaces session variables inside the query editor and warns when binlog_format conflicts with engine settings, letting you switch modes before running the statement.
.avif)
.avif){kind=logo}
