Oracle 5.0 Reference Manual page 1290

(negative infinity, 10]
(10, 11]
(11, 13]
(13, 20]
(20, positive infinity)
For the last interval, the next-key lock locks the gap above the largest value in the index and the
"supremum" pseudo-record having a value higher than any value actually in the index. The supremum
is not a real index record, so, in effect, this next-key lock locks only the gap following the largest index
value.
The preceding example shows that a gap might span a single index value, multiple index values, or
even be empty.
Gap locking is not needed for statements that lock rows using a unique index to search for a unique
row. (This does not include the case that the search condition includes only some columns of a
multiple-column unique index; in that case, gap locking does occur.) For example, if the
a unique index, the following statement uses only an index-record lock for the row having
and it does not matter whether other sessions insert rows in the preceding gap:
SELECT * FROM child WHERE id = 100;
If is not indexed or has a nonunique index, the statement does lock the preceding gap.
id
A type of gap lock called an insertion intention gap lock is set by
insertion. This lock signals the intent to insert in such a way that multiple transactions inserting into
the same index gap need not wait for each other if they are not inserting at the same position within
the gap. Suppose that there are index records with values of 4 and 7. Separate transactions that
attempt to insert values of 5 and 6 each lock the gap between 4 and 7 with insert intention locks prior
to obtaining the exclusive lock on the inserted row, but do not block each other because the rows are
nonconflicting.
Gap locking can be disabled explicitly. This occurs if you change the transaction isolation level to
COMMITTED
Under these circumstances, gap locking is disabled for searches and index scans and is used only for
foreign-key constraint checking and duplicate-key checking.
There is also another effect of using the
innodb_locks_unsafe_for_binlog
MySQL has evaluated the
14.2.7.5. Avoiding the Phantom Problem Using Next-Key Locking
The so-called phantom problem occurs within a transaction when the same query produces different
sets of rows at different times. For example, if a
second time that was not returned the first time, the row is a "phantom" row.
Suppose that there is an index on the
all rows from 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
contain rows having
range do not lock out inserts made in the gaps (in this case, the gap between 90 and 102), another
session can insert a new row into the table with an
within the same transaction, you would see a new row with an
returned by the query. If we regard a set of rows as a data item, the new phantom child would violate
the isolation principle of transactions that a transaction should be able to run so that the data it has
read does not change during the transaction.
The
InnoDB
[1121] or enable the
innodb_locks_unsafe_for_binlog
condition.
WHERE
values of 90 and 102. If the locks set on the index records in the scanned
id
Transaction Model and Locking
READ COMMITTED
[1244]: Record locks for nonmatching rows are released after
is executed twice, but returns a row the
SELECT
column of the
id child
of 101. If you were to execute the same
id
1270
operations prior to row
INSERT
[1244] system variable.
[1121] isolation level or enabling
table and that you want to read and lock
is bigger than 100. Let the table
id
of 101 (a "phantom") in the result set
id
column has
id
value 100
id
READ
SELECT