In terms of the SQL:1992 transaction isolation levels, the
InnoDB default is REPEATABLE
READ. InnoDB offers all four
transaction isolation levels described by the SQL standard. You
can set the default isolation level for all connections by using
the --transaction-isolation option on the
command line or in an option file. For example, you can set the
option in the [mysqld] section of an option
file like this:
[mysqld]
transaction-isolation = {READ-UNCOMMITTED | READ-COMMITTED
| REPEATABLE-READ | SERIALIZABLE}
A user can change the isolation level for a single session or
for all new incoming connections with the SET
TRANSACTION statement. Its syntax is as follows:
SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL
{READ UNCOMMITTED | READ COMMITTED
| REPEATABLE READ | SERIALIZABLE}
Note that there are hyphens in the level names for the
--transaction-isolation option, but not for the
SET TRANSACTION statement.
The default behavior is to set the isolation level for the next
(not started) transaction. If you use the
GLOBAL keyword, the statement sets the
default transaction level globally for all new connections
created from that point on (but not for existing connections).
You need the SUPER privilege to do this.
Using the SESSION keyword sets the default
transaction level for all future transactions performed on the
current connection.
Any client is free to change the session isolation level (even in the middle of a transaction), or the isolation level for the next transaction.
You can determine the global and session transaction isolation
levels by checking the value of the
tx_isolation system variable with these
statements:
SELECT @@global.tx_isolation; SELECT @@tx_isolation;
In row-level locking, InnoDB uses next-key
locking. That means that besides index records,
InnoDB can also lock the “gap”
preceding an index record to block insertions by other users
immediately before the index record. A next-key lock refers to a
lock that locks an index record and the gap before it. A gap
lock refers to a lock that only locks a gap before some index
record. Next-key locking for searches or index scans can be
disabled by enabling the
innodb_locks_unsafe_for_binlog system
variable.
A detailed description of each isolation level in
InnoDB follows:
For a detailed description of isolated levels, see
Section 12.4.6, “SET TRANSACTION Syntax”.

User Comments
If you are using java, servlets, hibernate with versioning, and mysql beware of the default repeatable read! Just because you get a new session or reconnect the session, it does not mean that "commit" has been called for you on the connection. Without automatically calling commit at the begining of getSession() or reconnect(), you'll end up occasionaly having problems. When the connection is used to read an object from the db, then another process comes along and changes the object with a commit, and then even when you force a refresh, change the data, and then try to write to the database you will encounter this problem. It will throw a net.sf.hibernate.StaleObjectStateException because the expected new version number was not given back by the database!
The solution is to switch to read committed. Otherwise once you get a new session call commit on the underlying connection.
This took some time to figure out. I'm more familiar with Oracle and I have never heard of anyone using repeatable read as the default. Repeatable read is more expensive and often times not needed.
Note that while executing a SERIALIZABLE mode transaction, one should not switch to REPEATABLE READ mode and back again as this leads to a transaction that is not properly serialized. Also note that next-key locking during index scans may be disabled with the setting innodb_locks_unsafe_for_binlog as mentioned in section 15.5. InnoDb Startup Options.
The section is a little confusing. It will help to have a succint explanation (maybe as a table) for these cases:
(1) When are locks held on index vs row (i.e. what if there is no index?)
(2) What takes place for each of the four isolation levels for
(a) Select .. (with and without index, with and without range)
(b) Select .. for update (with and without index, with and without range)
(c) Select .. lock in share mode (with and without index, with and without range)
(d) Update/delete with and without the use of indexed attribute (with and without index, with and without range)
And then there is a variation of consistent reads with multi-versioning!! What happens then?
I concur with Kurt's post. The definition of isolation levels unless it is consistent with what other db vendors provide, will not help Application developers(especially from Java platform) to keep the changes minimal. Even in-terms of understanding, it kind of surprised me to know that the default transaction isolation level is repeatable read and not read-committed. And the explanation in the manual is also not clear ,for what reasons why InnoDb opted to keep isolation level at repeatable read.
Add your own comment.