Easy MySQL: transaction isolation and ACID, the simple explanation

Clients often ask what the differences are between the various InnoDB isolation levels, or what ACID means. Here are some simple explanations for those that have not yet read the manual and committed it to memory.

READ UNCOMMITTED
Every select operates without locks so you don’t get consistency and might have dirt reads, which are potentially earlier versions of data. So, no ACID support here.

READ COMMITTED
Has consistent reads without locks. Each consistent read, even within the same transaction, sets and reads its own fresh snapshot.

REPEATABLE READ
The InnoDB default isolation level for ACID compliance. All reads within the same transaction will be consistent between each other – ie, the C in ACID. All writes will be durable, etc etc.

SERIALIZABLE
Same as REPEATABLE READ but MySQL converts regular select statements with preface of LOCK IN SHARED MODE when autocommit is enabled. If it’s disabled then each select is started in a separate transaction which will always make sure that reads are consistent. It also, uh, allows for XA distributed transactions support. You have to be using SERIALIZABLE to correctly use XA transactions.

===========================================================================

ATOMICITY
All transactions fail or no transactions fail. Basically that if a transaction fails because of a hardware issue, connection issue, etc – that  partial changes won’t commit. It’s 100% or 0% operation.

CONSISTENCY
Data being read by a select is all at the same state. So when you use a transaction you’re getting the most current and consistent data available. This is related to MVCC (multi version concurrency control)

ISOLATION
Nothing that’s being read is actively being changed by another transaction.  Your connection or transaction’s read is not going to be changed by another transaction while you’re dealing with that data.

DURABILITY
Changes to the database persist – basically that means that if a transaction is committed and the DB fails or server crashes your changes will be there – which is why innodb uses transaction log files (where data is kept before being written to disk. The engine will read the logs on next startup and commit any remaining transactions in the logs that did not make to disk based tables.)

Image may be NSFW.
Clik here to view.