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 COMMIT before
executing the statement.
Most of these statements also cause an implicit commit after executing. The intent is to handle each such statement in its own special transaction because it cannot be rolled back anyway. Transaction-control and locking statements are exceptions: If an implicit commit occurs before execution, another does not occur after.
Data definition language (DDL)
statements that define or modify database objects.
ALTER DATABASE ... UPGRADE DATA DIRECTORY
NAME, ALTER EVENT,
ALTER PROCEDURE,
ALTER SERVER,
ALTER TABLE,
ALTER VIEW,
CREATE DATABASE,
CREATE EVENT,
CREATE INDEX,
CREATE PROCEDURE,
CREATE SERVER,
CREATE TABLE,
CREATE TRIGGER,
CREATE VIEW,
DROP DATABASE,
DROP EVENT,
DROP INDEX,
DROP PROCEDURE,
DROP SERVER,
DROP TABLE,
DROP TRIGGER,
DROP VIEW,
RENAME TABLE,
TRUNCATE TABLE.
ALTER FUNCTION,
CREATE FUNCTION and
DROP FUNCTION also cause an
implicit commit when used with stored functions, but not with
user-defined functions. (ALTER
FUNCTION can only be used with stored functions.)
CREATE TABLE and
DROP TABLE statements do not
commit a transaction if the TEMPORARY
keyword is used. (This does not apply to other operations on
temporary tables such as ALTER
TABLE and CREATE
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
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.
CREATE TABLE ...
SELECT causes an implicit commit before and after
the statement is executed when you are creating nontemporary
tables. (No commit occurs for CREATE TEMPORARY TABLE
... SELECT.) This is to prevent an issue during
replication where the table could be created on the master
after a rollback, but fail to be recorded in the binary log,
and therefore not replicated to the slave.
Statements that implicitly use or modify
tables in the mysql database.
ALTER USER,
CREATE USER,
DROP USER,
GRANT,
RENAME USER,
REVOKE,
SET PASSWORD.
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 to acquire nontransactional table locks. A
commit 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 13.6.1, “BEGIN ... END Compound-Statement Syntax”.
Data loading statements.
LOAD DATA
INFILE.
LOAD DATA
INFILE causes an implicit commit only for tables
using the NDB storage engine.
Administrative statements.
ANALYZE TABLE,
CACHE INDEX,
CHECK TABLE,
FLUSH,
LOAD INDEX INTO
CACHE, OPTIMIZE
TABLE, REPAIR TABLE,
RESET.
Replication control
statements. Beginning with MySQL 5.6.7:
START SLAVE,
STOP SLAVE,
RESET SLAVE,
CHANGE MASTER TO. (Bug
#13858841)