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.