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
statement.
Data definition language (DDL)
statements that define or modify database objects.
ALTER TABLE,
CREATE INDEX,
DROP INDEX,
DROP TABLE,
RENAME TABLE.
ALTER TABLE,
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 CREATE INDEX,
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
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.
Prior to MySQL 4.0.13, CREATE
TABLE commits a transaction if the binary update log
is enabled. The CREATE TABLE,
CREATE DATABASE
DROP DATABASE, and
TRUNCATE TABLE statements cause
an implicit commit beginning with MySQL 4.1.13.
Transaction-control and locking
statements.
BEGIN,
LOCK TABLES, SET
autocommit = 1 (if the value is not already 1),
START
TRANSACTION,
UNLOCK
TABLES.
UNLOCK
TABLES commits a transaction only if any tables
currently have been locked with LOCK
TABLES. This does not occur for
UNLOCK
TABLES following
FLUSH TABLES WITH READ
LOCK because the latter statement does not acquire
table-level locks.
Transactions cannot be nested. This is a consequence of the
implicit commit performed for any current transaction when you
issue a START
TRANSACTION statement or one of its synonyms.
Data loading statements.
LOAD MASTER DATA.

User Comments
Add your own comment.