I am reading up on transactions in MySQL and am not sure whether I have grasped something specific correctly, and I want to be sure I understood that correctly, so here goes. I know what a transaction is supposed to do, I’m just not sure whether I understood the statement semantics or not.
So, my question is, is anything wrong, (and, if that is the case, what is wrong) with the following:
By default, autocommit mode is enabled in MySQL.
SET autocommit=0; will begin a transaction,
SET autocommit=1; will implicitly commit. It is possible to
COMMIT; as well as
ROLLBACK;, in both of which cases autocommit is still set to 0 afterwards (and a new transaction is implicitly started).
START TRANSACTION; will basically
SET autocommit=0; until a
ROLLBACK; takes place.
In other words,
START TRANSACTION; and
SET autocommit=0; are equivalent, except for the fact that
START TRANSACTION; does the equivalent of implicitly adding a
SET autocommit=0; after
If that is the case, I don’t understand http://dev.mysql.com/doc/refman/5.5/en/set-transaction.html#isolevel_serializable – seeing as having an isolation level implies that there is a transaction, meaning that autocommit should be off anyway?
And if there is another difference (other than the one described above) between beginning a transaction and setting autocommit, what is it?
Being aware of the transaction (autocommit, explicit and implicit) handling for your database can save you from having to restore data from a backup.
Transactions control data manipulation statement(s) to ensure they are atomic. Being “atomic” means the transaction either occurs, or it does not. The only way to signal the completion of the transaction to database is by using either a
ROLLBACK statement (per ANSI-92, which sadly did not include syntax for creating/beginning a transaction so it is vendor specific).
COMMIT applies the changes (if any) made within the transaction.
ROLLBACK disregards whatever actions took place within the transaction – highly desirable when an UPDATE/DELETE statement does something unintended.
Typically individual DML (Insert, Update, Delete) statements are performed in an autocommit transaction – they are committed as soon as the statement successfully completes. Which means there’s no opportunity to roll back the database to the state prior to the statement having been run in cases like yours. When something goes wrong, the only restoration option available is to reconstruct the data from a backup (providing one exists). In MySQL, autocommit is on by default for InnoDB – MyISAM doesn’t support transactions. It can be disabled by using:
SET autocommit = 0
An explicit transaction is when statement(s) are wrapped within an explicitly defined transaction code block – for MySQL, that’s
START TRANSACTION. It also requires an explicitly made
ROLLBACK statement at the end of the transaction. Nested transactions is beyond the scope of this topic.
Implicit transactions are slightly different from explicit ones. Implicit transactions do not require explicity defining a transaction. However, like explicit transactions they require a
ROLLBACK statement to be supplied.
Explicit transactions are the most ideal solution – they require a statement,
ROLLBACK, to finalize the transaction, and what is happening is clearly stated for others to read should there be a need. Implicit transactions are OK if working with the database interactively, but
COMMIT statements should only be specified once results have been tested & thoroughly determined to be valid.
That means you should use:
SET autocommit = 0; START TRANSACTION; UPDATE ...;
…and only use
COMMIT; when the results are correct.
That said, UPDATE and DELETE statements typically only return the number of rows affected, not specific details. Convert such statements into SELECT statements & review the results to ensure correctness prior to attempting the UPDATE/DELETE statement.
DDL (Data Definition Language) statements are automatically committed – they do not require a COMMIT statement. IE: Table, index, stored procedure, database, and view creation or alteration statements.
In InnoDB you have
START TRANSACTION;, which in this engine is the officialy recommended way to do transactions, instead of
SET AUTOCOMMIT = 0; (don’t use
SET AUTOCOMMIT = 0; for transactions in InnoDB unless it is for optimizing read only transactions). Commit with
You might want to use
SET AUTOCOMMIT = 0; in InnoDB for testing purposes, and not precisely for transactions.
In MyISAM you do not have
START TRANSACTION; in this engine, use
SET AUTOCOMMIT = 0; for transactions. Commit with
SET AUTOCOMMIT = 1; (Difference explained in MyISAM example commentary below). You can do transactions this way in InnoDB too.
Examples of general use transactions:
/* InnoDB */ START TRANSACTION; INSERT INTO table_name (table_field) VALUES ('foo'); INSERT INTO table_name (table_field) VALUES ('bar'); COMMIT; /* SET AUTOCOMMIT = 1 might not set AUTOCOMMIT to its previous state */ /* MyISAM */ SET AUTOCOMMIT = 0; INSERT INTO table_name (table_field) VALUES ('foo'); INSERT INTO table_name (table_field) VALUES ('bar'); SET AUTOCOMMIT = 1 /* COMMIT statement instead would not restore AUTOCOMMIT to 1 */;
If you want to use rollback, then use start transaction and otherwise forget all those things, since MySQL sets
autocommit to 1 by default.