ALTER TABLE, BEGIN, CREATE INDEX, DROP INDEX, DROP TABLE, LOAD MASTER DATA, LOCK TABLES, LOAD DATA INFILE, RENAME TABLE, SET AUTOCOMMIT=1 (if the value is not already 1), START TRANSACTION, UNLOCK TABLES.

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 21.2.5, “BEGIN ... END Compound Statement Syntax”.

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, and DROP PROCEDURE cause an implicit commit.

Beginning with MySQL 5.0.15, ALTER VIEW, CREATE TRIGGER, CREATE USER, CREATE VIEW, DROP TRIGGER, DROP USER, DROP VIEW, and RENAME USER cause an implicit commit.

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.

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 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.

In MySQL 5.0.25 and earlier, LOAD DATA INFILE caused an implicit commit for all storage engines. Beginning with MySQL 5.0.26, it causes an implicit commit only for tables using the NDB storage engine. For more information, see Bug#11151.