13.3.3 Statements That Cause an Implicit Commit

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. As of MySQL 5.5.3, most of these
statements also cause an implicit commit after executing; for
additional details, see the end of this section.

CREATE TABLE and
DROP TABLE statements do not
commit a transaction if the TEMPORARY
keyword is used. (This does not apply to other operations on
temporary tables such as ALTER
TABLE and CREATE
INDEX, which do cause a commit.) However, although
no implicit commit occurs, neither can the statement be rolled
back, which means that the use of such statements causes
transactional atomicity to be violated. For example, if you
use CREATE
TEMPORARY TABLE and then roll back the transaction,
the table remains in existence.

The CREATE TABLE statement in
InnoDB is processed as a single
transaction. This means that a
ROLLBACK
from the user does not undo CREATE
TABLE statements the user made during that
transaction.

CREATE TABLE ...
SELECT causes an implicit commit before and after
the statement is executed when you are creating nontemporary
tables. (No commit occurs for CREATE TEMPORARY TABLE
... SELECT.) This is to prevent an issue during
replication where the table could be created on the master
after a rollback, but fail to be recorded in the binary log,
and therefore not replicated to the slave. For more
information, see Bug #22865.

As of MySQL 5.5.3, most statements that previously caused an
implicit commit before executing also do so after executing. The
intent is to handle each such statement in its own special
transaction because it cannot be rolled back anyway. The following
list provides additional details pertaining to this change: