Oracle 5.0 Reference Manual page 1291

To prevent phantoms,
locking with gap locking.
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
index, another session cannot insert a new index record in the gap immediately before
order.
When
InnoDB
happens in the preceding example: To prevent any insert into the table where
100, the locks set by
You can use next-key locking to implement a uniqueness check in your application: If you read your
data in share mode and do not see a duplicate for a row you are going to insert, then you can safely
insert your row and know that the next-key lock set on the successor of your row during the read
prevents anyone meanwhile inserting a duplicate for your row. Thus, the next-key locking enables you
to "lock" the nonexistence of something in your table.
Gap locking can be disabled as discussed in
Locks". This may cause phantom problems because other sessions can insert new rows into the gaps
when gap locking is disabled.
14.2.7.6. Locks Set by Different SQL Statements in
A locking read, an UPDATE, or a
is scanned in the processing of the SQL statement. It does not matter whether there are
conditions in the statement that would exclude the row.
condition, but only knows which index ranges were scanned. The locks are normally next-key locks that
also block inserts into the "gap" immediately before the record. However, gap locking can be disabled
explicitly, which causes next-key locking not to be used. For more information, see
"InnoDB Record, Gap, and Next-Key
are set; see
If a secondary index is used in a search and index record locks to be set are exclusive,
retrieves the corresponding clustered index records and sets locks on them.
Differences between shared and exclusive locks are described in
Modes".
If you have no indexes suitable for your statement and MySQL must scan the entire table to process
the statement, every row of the table becomes locked, which in turn blocks all inserts by other users to
the table. It is important to create good indexes so that your queries do not unnecessarily scan many
rows.
For
SELECT ... FOR UPDATE
scanned rows, and expected to be released for rows that do not qualify for inclusion in the result set
(for example, if they do not meet the criteria given in the
rows might not be unlocked immediately because the relationship between a result row and its original
source is lost during query execution. For example, in a UNION, scanned (and locked) rows from a
table might be inserted into a temporary table before evaluation whether they qualify for the result set.
In this circumstance, the relationship of the rows in the temporary table to the rows in the original table
is lost and the latter rows are not unlocked until the end of query execution.
sets specific types of locks as follows.
InnoDB
•
SELECT ... FROM
unless the transaction isolation level is set to
level, the search sets shared next-key locks on the index records it encounters.
The
InnoDB
uses an algorithm called next-key locking that combines index-row
InnoDB
performs row-level locking in such a way that when it searches or
InnoDB
scans an index, it can also lock the gap after the last record in the index. Just that
include a lock on the gap following
InnoDB
DELETE
Section 13.3.6, "SET TRANSACTION
or
is a consistent read, reading a snapshot of the database and setting no locks
Transaction Model and Locking
Section 14.2.7.4,
InnoDB
generally set record locks on every index record that
InnoDB
Locks". The transaction isolation level also can affect which locks
Syntax".
SELECT ... LOCK IN SHARE
WHERE
SERIALIZABLE
1271
would be bigger than
id
value 102.
id
"InnoDB Record, Gap, and Next-Key
does not remember the exact
Section 14.2.7.4,
Section 14.2.7.1, "InnoDB
MODE, locks are acquired for
clause). However, in some cases,
[1121]. For
SERIALIZABLE
in an
R
in the index
R
WHERE
WHERE
also
InnoDB
Lock
[1121]