START TRANSACTION, COMMIT, and ROLLBACK Statements SET autocommit=0; After disabling autocommit mode by setting the  autocommit  variable to zero, changes to transaction-safe tables (such as those for  InnoDB  or  NDB ) are not made permanent immediately. You must use  COMMIT  to store your changes to disk or  ROLLBACK  to ignore the changes. autocommit  is a session variable and must be set for each session. To disable autocommit mode for each new connection, see the description of the  autocommit  system variable at Section 5.1.8, “Server System Variables” . BEGIN  and  BEGIN WORK  are supported as aliases of  START TRANSACTION  for initiating a transaction. START TRANSACTION  is standard SQL syntax, is the recommended way to start an ad-hoc transaction, and permits modifiers that  BEGIN  does not. The  BEGIN  statement differs from the use of the  BEGIN  keyword that starts a  BEGIN ... END  compound statement. The latter does not begin a transaction. See Section 13.6.1, “BEGIN ... END Compound Statement” . Within all stored programs (stored procedures and functions, triggers, and events), the parser treats  BEGIN [WORK]  as the beginning of a  BEGIN ... END  block. Begin a transaction in this context with  START TRANSACTION  instead. The optional  WORK  keyword is supported for  COMMIT  and  ROLLBACK , as are the  CHAIN  and  RELEASE clauses.  CHAIN  and  RELEASE  can be used for additional control over transaction completion. The value of the  completion_type  system variable determines the default completion behavior. See Section 5.1.8, “Server System Variables” . The  AND CHAIN  clause causes a new transaction to begin as soon as the current one ends, and the new transaction has the same isolation level as the just-terminated transaction. The new transaction also uses the same access mode ( READ WRITE  or  READ ONLY ) as the just-terminated transaction. The RELEASE  clause causes the server to disconnect the current client session after terminating the current transaction. Including the  NO  keyword suppresses  CHAIN  or  RELEASE  completion, which can be useful if the  completion_type  system variable is set to cause chaining or release completion by default. Beginning a transaction causes any pending transaction to be committed. See Section 13.3.3, “Statements That Cause an Implicit Commit” , for more information. Beginning a transaction also causes table locks acquired with  LOCK TABLES  to be released, as though you had executed  UNLOCK TABLES . Beginning a transaction does not release a global read lock acquired with  FLUSH TABLES WITH READ LOCK . For best results, transactions should be performed using only tables managed by a single transaction-safe storage engine. Otherwise, the following problems can occur: 2722 •If you use tables that are not transaction-safe within a transaction, changes to those tables are stored at once, regardless of the status of autocommit mode. •If you use tables from more than one transaction-safe storage engine (such as  InnoDB ), and the transaction isolation level is not  SERIALIZABLE , it is possible that when one transaction commits, another ongoing transaction that uses the same tables sees only some of the changes made by the first transaction. That is, the atomicity of transactions is not guaranteed with mixed engines and inconsistencies can result. (If mixed-engine transactions are infrequent, you can use  SET TRANSACTION ISOLATION LEVEL  to set the isolation level to  SERIALIZABLE  on a per-transaction basis as necessary.) Note