The statements listed in this section (and any synonyms for them)
implicitly end a transaction, as if you had done a
COMMIT before executing the
CREATE TABLE, and
DROP TABLE do not commit a
transaction if the
TEMPORARY keyword is
used. (This does not apply to other operations on temporary
tables such as
which do cause a commit.) However, although no implicit commit
occurs, neither can the statement be rolled back. Therefore,
use of such statements will violate transaction atomicity: For
example, if you use
TABLE and then roll back the transaction, the table
remains in existence.
Prior to MySQL 4.0.13,
TABLE commits a transaction if the binary update log
is enabled. The
DROP DATABASE, and
TRUNCATE TABLE statements cause
an implicit commit beginning with MySQL 4.1.13.
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.
Data loading statements.
LOAD MASTER DATA.