Oracle 5.0 Reference Manual page 1293

DELETE FROM t1 WHERE i = 1;
Session 2:
START TRANSACTION;
INSERT INTO t1 VALUES(1);
Session 3:
START TRANSACTION;
INSERT INTO t1 VALUES(1);
Session 1:
COMMIT;
The first operation by session 1 acquires an exclusive lock for the row. The operations by sessions
2 and 3 both result in a duplicate-key error and they both request a shared lock for the row. When
session 1 commits, it releases its exclusive lock on the row and the queued shared lock requests
for sessions 2 and 3 are granted. At this point, sessions 2 and 3 deadlock: Neither can acquire an
exclusive lock for the row because of the shared lock held by the other.
•
INSERT ... ON DUPLICATE KEY UPDATE
next-key lock rather than a shared lock is placed on the row to be updated when a duplicate-key
error occurs.
• is done like an
REPLACE
next-key lock is placed on the row to be replaced.
•
INSERT INTO T SELECT ... FROM S WHERE ...
gap lock on each row inserted into T. If
and the transaction isolation level is not
consistent read (no locks). Otherwise,
has to set locks in the latter case: In roll-forward recovery from a backup, every SQL statement must
be executed in exactly the same way it was done originally.
CREATE TABLE ... SELECT ...
consistent read, as for
For
REPLACE INTO T SELECT ... FROM S WHERE
rows from S.
• While initializing a previously specified
exclusive lock on the end of the index associated with the
the auto-increment counter,
only to the end of the current SQL statement, not to the end of the entire transaction. Other sessions
cannot insert into the table while the
Transaction Model and
fetches the value of a previously initialized
InnoDB
locks.
• If a constraint is defined on a table, any insert, update, or delete that requires the
FOREIGN KEY
constraint condition to be checked sets shared record-level locks on the records that it looks at to
check the constraint.
• sets table locks, but it is the higher MySQL layer above the
LOCK TABLES
sets these locks.
InnoDB
[436], and the MySQL layer above
autocommit = 0
Otherwise, InnoDB's automatic deadlock detection cannot detect deadlocks where such table locks
are involved. Also, because in this case the higher MySQL layer does not know about row-level
locks, it is possible to get a table lock on a table where another session currently has row-level locks.
The Transaction Model and Locking
InnoDB
if there is no collision on a unique key. Otherwise, an exclusive
INSERT
innodb_locks_unsafe_for_binlog
SERIALIZABLE
InnoDB
performs the
INSERT ... SELECT.
AUTO_INCREMENT
uses a specific
InnoDB
AUTO-INC
Locking".
also sets these locks in the case where the constraint fails.
InnoDB
is aware of table locks if
1273
differs from a simple
INSERT
sets an exclusive index record without a
[1121],
InnoDB
sets shared next-key locks on rows from S.
with shared next-key locks or as a
SELECT
..., InnoDB
column on a table,
AUTO_INCREMENT
table lock mode where the lock lasts
AUTO-INC
table lock is held; see
AUTO_INCREMENT
innodb_table_locks = 1
knows about row-level locks.
InnoDB
in that an exclusive
[1244] is enabled
does the search on
S
InnoDB
sets shared next-key locks on
sets an
InnoDB
column. In accessing
Section 14.2.7, "The
InnoDB
column without setting any
layer that
InnoDB
(the default) and
as a