The Binary Log For information about determining system variable scope, see Section 5.1.9, “Using System Variables” . For information about how replication treats  sql_mode , see Section 17.5.1.39, “Replication and Variables” . In earlier releases, when mixed binary logging format was in use, if a statement was logged by row and the session that executed the statement had any temporary tables, all subsequent statements were treated as unsafe and logged in row-based format until all temporary tables in use by that session were dropped. As of MySQL 8.0, operations on temporary tables are not logged in mixed binary logging format, and the presence of temporary tables in the session has no impact on the logging mode used for each statement. A warning is generated if you try to execute a statement using statement-based logging that should be written using row-based logging. The warning is shown both in the client (in the output of  SHOW WARNINGS ) and through the  mysqld  error log. A warning is added to the  SHOW WARNINGS  table each time such a statement is executed. However, only the first statement that generated the warning for each client session is written to the error log to prevent flooding the log. In addition to the decisions above, individual engines can also determine the logging format used when information in a table is updated. The logging capabilities of an individual engine can be defined as follows: A given storage engine can support either or both logging formats. The following table lists the formats supported by each engine. Whether a statement is to be logged and the logging mode to be used is determined according to the type of statement (safe, unsafe, or binary injected), the binary logging format ( STATEMENT ,  ROW , or  MIXED ), and the logging capabilities of the storage engine (statement capable, row capable, both, or neither). (Binary injection refers to logging a change that must be logged using  ROW  format.) Statements may be logged with or without a warning; failed statements are not logged, but generate errors in the log. This is shown in the following decision table.  Type ,  binlog_format ,  SLC , and  RLC  columns 1055 Note •If an engine supports row-based logging, the engine is said to be  row-logging capable . •If an engine supports statement-based logging, the engine is said to be  statement-logging capable . Storage Engine Row Logging Supported Statement Logging Supported ARCHIVE Yes Yes BLACKHOLE Yes Yes CSV Yes Yes EXAMPLE Yes No FEDERATED Yes Yes HEAP Yes Yes InnoDB Yes Yes when the transaction isolation level is  REPEATABLE READ  or SERIALIZABLE ; No otherwise. MyISAM Yes Yes MERGE Yes Yes NDB Yes No