The world's most popular open source database
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.
Beginning with MySQL 5.0.8, CREATE
TABLE, CREATE
DATABASE DROP
DATABASE, and
TRUNCATE
TABLE cause an implicit commit.
Beginning with MySQL 5.0.13, ALTER
FUNCTION, ALTER PROCEDURE,
CREATE FUNCTION, CREATE
PROCEDURE, DROP FUNCTION (for
stored functions, not UDFs), and DROP
PROCEDURE cause an implicit commit.
Beginning with MySQL 5.0.15, ALTER
VIEW, CREATE TRIGGER,
CREATE VIEW,
DROP TRIGGER, and
DROP VIEW cause an implicit
commit.
Statements that implicitly use or modify
tables in the mysql database.
Beginning with MySQL 5.0.15, CREATE
USER, DROP USER, and
RENAME USER cause an implicit
commit.
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.
Statements that cause an implicit commit cannot be used in an
XA transaction while the transaction is in an
ACTIVE state.
The BEGIN
statement differs from the use of the BEGIN
keyword that starts a BEGIN ... END
compound statement. The latter does not cause an implicit
commit. See Section 12.8.1, “BEGIN ... END Compound Statement Syntax”.
Data loading statements.
LOAD MASTER DATA,
LOAD DATA
INFILE. Before MySQL 5.0.26,
LOAD DATA
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 NDB storage engine.
For more information, see Bug#11151.


User Comments
Add your own comment.