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
executing the statement.
CREATE TABLE and
DROP TABLE statements do not
commit a transaction if the
keyword is used. (This does not apply to other operations on
temporary tables such as
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
TEMPORARY TABLE and then roll back the transaction,
the table remains in existence.
Also beginning with MySQL 5.0.13,
FUNCTION cause an implicit commit when used with
stored functions, but not with UDFs.
ALTER FUNCTION can only be
used with stored functions.)
TABLES commits a transaction only if any tables
currently have been locked with
TABLES. This does not occur for
FLUSH TABLES WITH READ
LOCK because the latter statement does not acquire
Transactions cannot be nested. This is a consequence of the
implicit commit performed for any current transaction when you
TRANSACTION statement or one of its synonyms.
Statements that cause an implicit commit cannot be used in an
XA transaction while the transaction is in an
statement differs from the use of the
keyword that starts a
END compound statement. The latter does not cause an
implicit commit. See Section 13.6.1, “
BEGIN ... END
Data loading statements.
LOAD MASTER DATA,
INFILE. Before MySQL 5.0.26,
INFILE caused an implicit commit for all storage
engines. As of MySQL 5.0.26, it causes an implicit commit only
for tables using the
engine. For more information, see Bug #11151.