Statements That Cannot Be Rolled Back •If you issue a  ROLLBACK  statement after updating a nontransactional table within a transaction, an ER_WARNING_NOT_COMPLETE_ROLLBACK  warning occurs. Changes to transaction-safe tables are rolled back, but not changes to nontransaction-safe tables. Each transaction is stored in the binary log in one chunk, upon  COMMIT . Transactions that are rolled back are not logged. ( Exception : Modifications to nontransactional tables cannot be rolled back. If a transaction that is rolled back includes modifications to nontransactional tables, the entire transaction is logged with a ROLLBACK  statement at the end to ensure that modifications to the nontransactional tables are replicated.) See Section 5.4.4, “The Binary Log” . You can change the isolation level or access mode for transactions with the  SET TRANSACTION statement. See Section 13.3.7, “SET TRANSACTION Statement” . Rolling back can be a slow operation that may occur implicitly without the user having explicitly asked for it (for example, when an error occurs). Because of this,  SHOW PROCESSLIST  displays  Rolling back  in the  State  column for the session, not only for explicit rollbacks performed with the  ROLLBACK  statement but also for implicit rollbacks. In MySQL 8.0,  BEGIN ,  COMMIT , and  ROLLBACK  are not affected by  --replicate- do-db  or  --replicate-ignore-db  rules. When  InnoDB  performs a complete rollback of a transaction, all locks set by the transaction are released. If a single SQL statement within a transaction rolls back as a result of an error, such as a duplicate key error, locks set by the statement are preserved while the transaction remains active. This happens because  InnoDB  stores row locks in a format such that it cannot know afterward which lock was set by which statement. If a  SELECT  statement within a transaction calls a stored function, and a statement within the stored function fails, that statement rolls back. If  ROLLBACK  is executed for the transaction subsequently, the entire transaction rolls back. Some statements cannot be rolled back. In general, these include data definition language (DDL) statements, such as those that create or drop databases, those that create, drop, or alter tables or stored routines. You should design your transactions not to include such statements. If you issue a statement early in a transaction that cannot be rolled back, and then another statement later fails, the full effect of the transaction cannot be rolled back in such cases by issuing a  ROLLBACK  statement. The statements listed in this section (and any synonyms for them) implicitly end any transaction active in the current session, as if you had done a  COMMIT  before executing the statement. Most of these statements also cause an implicit commit after executing. The intent is to handle each such statement in its own special transaction. Transaction-control and locking statements are exceptions: If an implicit commit occurs before execution, another does not occur after. • Data definition language (DDL) statements that define or modify database objects. ALTER EVENT ,  ALTER FUNCTION ,  ALTER PROCEDURE ,  ALTER SERVER ,  ALTER TABLE ,  ALTER VIEW , 13.3.2 Statements That Cannot Be Rolled Back 13.3.3 Statements That Cause an Implicit Commit Note 2723