ALTER EVENT, ALTER FUNCTION, ALTER FUNCTION, ALTER PROCEDURE, ALTER TABLE, BEGIN, CREATE DATABASE, CREATE EVENT, CREATE FUNCTION, CREATE INDEX, CREATE PROCEDURE, CREATE TABLE, DROP DATABASE, DROP EVENT, DROP FUNCTION, DROP INDEX, DROP PROCEDURE, DROP TABLE, LOAD DATA INFILE LOCK TABLES, RENAME TABLE, SET AUTOCOMMIT=1, START TRANSACTION, TRUNCATE TABLE, UNLOCK TABLES.

Beginning with MySQL 5.1.3, the ALTER VIEW, CREATE TRIGGER, CREATE USER, CREATE VIEW, DROP TRIGGER, DROP USER, DROP VIEW, and RENAME USER statements 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.)

Beginning with MySQL 5.1.15, CREATE TABLE ... SELECT causes an implicit commit before and after the statement is executed. However, no commit occurs for CREATE TEMPORARY TABLE ... SELECT.

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

In MySQL 5.1.15 and later, CREATE TABLE ... SELECT statements include an implicit commit when you are creating non-temporary tables. 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. For more information, see Bug#22865.