Oracle 5.0 Reference Manual page 1265

InnoDB
This variable affects how
uses an algorithm called next-key locking that combines index-row locking with gap locking.
performs row-level locking in such a way that when it searches or scans a table index, it sets shared
or exclusive locks on the index records it encounters. Thus, the row-level locks are actually index-
record locks. In addition, a next-key lock on an index record also affects the "gap" before that
index record. That is, a next-key lock is an index-record lock plus a gap lock on the gap preceding
the index record. If one session has a shared or exclusive lock on record
session cannot insert a new index record in the gap immediately before
Section 14.2.7.4, "InnoDB
By default, the value of
that gap locking is enabled:
the variable, set it to 1. This causes gap locking to be disabled:
for searches and index scans.
Enabling
innodb_locks_unsafe_for_binlog
foreign-key constraint checking or duplicate-key checking.
The effect of enabling
innodb_locks_unsafe_for_binlog
to setting the transaction isolation level to
• Enabling
innodb_locks_unsafe_for_binlog
sessions, whereas the isolation level can be set globally for all sessions, or individually per
session.
•
innodb_locks_unsafe_for_binlog
isolation level can be set at startup or changed at runtime.
[1121]
READ COMMITTED
innodb_locks_unsafe_for_binlog
level on gap locking, see
Enabling
innodb_locks_unsafe_for_binlog
other sessions can insert new rows into the gaps when gap locking is disabled. Suppose that there
is an index on the column of the
id
the table having an identifier value larger than 100, with the intention of updating some column in the
selected rows later:
SELECT * FROM child WHERE id > 100 FOR UPDATE;
The query scans the index starting from the first record where
set on the index records in that range do not lock out inserts made in the gaps, another session
can insert a new row into the table. Consequently, if you were to execute the same
within the same transaction, you would see a new row in the result set returned by the query. This
also means that if new items are added to the database,
Therefore, if
innodb_locks_unsafe_for_binlog
most an isolation level of
additional information about phantoms, see
Next-Key Locking".
Starting from MySQL 5.0.2, enabling
additional effect. For
UPDATE
updates or deletes. Record locks for nonmatching rows are released after MySQL has evaluated the
condition. This greatly reduces the probability of deadlocks, but they can still happen. Note
WHERE
Startup Options and System Variables
Permitted Values
Type
boolean
Default
OFF
uses gap locking for searches and index scans. Normally,
InnoDB
Record, Gap, and Next-Key
innodb_locks_unsafe_for_binlog
uses next-key locks for searches and index scans. To enable
InnoDB
READ COMMITTED
[1244]
therefore offers finer and more flexible control than
[1244]. For additional details about the effect of isolation
Section 13.3.6, "SET TRANSACTION
table and that you want to read and lock all rows from
child
[1121]. (Conflict serializability is still guaranteed.) For
READ COMMITTED
Section 14.2.7.5, "Avoiding the Phantom Problem Using
innodb_locks_unsafe_for_binlog
or statements,
DELETE
1245
R
R
Locks".
[1244] is 0 (disabled), which means
uses only index-record locks
InnoDB
[1244] does not disable the use of gap locking for
[1244] is similar to but not identical
[1121]:
[1244] is a global setting and affects all
can be set only at server startup, whereas the
Syntax".
[1244] may cause phantom problems because
is greater than 100. If the locks
id
does not guarantee serializability.
InnoDB
[1244] is enabled,
InnoDB
holds locks only for rows that it
InnoDB
InnoDB
InnoDB
in an index, another
in the index order. See
again
SELECT
guarantees at
[1244] has an