Syntax:
SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL
  {
       READ UNCOMMITTED
     | READ COMMITTED
     | REPEATABLE READ
     | SERIALIZABLE
   }

This statement sets the transaction isolation level for the next
transaction, globally, or for the current session.

The default behavior of SET TRANSACTION is to set the isolation level
for the next (not yet 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. Existing connections
are unaffected. 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.

For information about InnoDB and transaction isolation level, see
http://dev.mysql.com/doc/refman/5.0/en/innodb-transaction-isolation.htm
l. InnoDB supports each of the levels described here in MySQL 5.0. The
default level is REPEATABLE READ. See also
http://dev.mysql.com/doc/refman/5.0/en/innodb-locks-set.html, for
additional information about how InnoDB uses locks to execute various
types of statements.

To set the initial default global isolation level for mysqld, use the
--transaction-isolation option. See
http://dev.mysql.com/doc/refman/5.0/en/server-options.html.

A detailed list of the transaction levels supported by MySQL and the
various storage engines follows:

o READ UNCOMMITTED

  SELECT statements are performed in a non-locking fashion, but a
  possible earlier version of a record might be used. Thus, using this
  isolation level, such reads are not consistent. This is also called a
  "dirty read." Otherwise, this isolation level works like READ
  COMMITTED.

o READ COMMITTED

  A somewhat Oracle-like isolation level. All SELECT ... FOR UPDATE and
  SELECT ... LOCK IN SHARE MODE statements lock only the index records,
  not the gaps before them, and thus allow the free insertion of new
  records next to locked records. UPDATE and DELETE statements using a
  unique index with a unique search condition lock only the index
  record found, not the gap before it. In range-type UPDATE and DELETE
  statements, InnoDB must set next-key or gap locks and block
  insertions by other users to the gaps covered by the range. This is
  necessary because "phantom rows" must be blocked for MySQL
  replication and recovery to work.

  Consistent reads behave as in Oracle: Each consistent read, even
  within the same transaction, sets and reads its own fresh snapshot.
  See
  http://dev.mysql.com/doc/refman/5.0/en/innodb-consistent-read.html.

o REPEATABLE READ

  This is the default isolation level of InnoDB. SELECT ... FOR UPDATE,
  SELECT ... LOCK IN SHARE MODE, UPDATE, and DELETE statements that use
  a unique index with a unique search condition lock only the index
  record found, not the gap before it. With other search conditions,
  these operations employ next-key locking, locking the index range
  scanned with next-key or gap locks, and block new insertions by other
  users.

  In consistent reads, there is an important difference from the READ
  COMMITTED isolation level: All consistent reads within the same
  transaction read the same snapshot established by the first read.
  This convention means that if you issue several plain SELECT
  statements within the same transaction, these SELECT statements are
  consistent also with respect to each other. See
  http://dev.mysql.com/doc/refman/5.0/en/innodb-consistent-read.html.

o SERIALIZABLE

  This level is like REPEATABLE READ, but InnoDB implicitly converts
  all plain SELECT statements to SELECT ... LOCK IN SHARE MODE.

URL: http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html

