Oracle 5.0 Reference Manual page 1294

However, this does not endanger transaction integrity, as discussed in
Detection and
14.2.7.7. Implicit Transaction Commit and Rollback
By default, MySQL starts the session for each new connection with autocommit mode enabled,
so MySQL does a commit after each SQL statement if that statement did not return an error. If a
statement returns an error, the commit or rollback behavior depends on the error. See
"InnoDB Error
If a session that has autocommit disabled ends without explicitly committing the final transaction,
MySQL rolls back that transaction.
Some statements implicitly end a transaction, as if you had done a
statement. For details, see
14.2.7.8. Deadlock Detection and Rollback
automatically detects transaction deadlocks and rolls back a transaction or transactions to
InnoDB
break the deadlock.
is determined by the number of rows inserted, updated, or deleted.
is aware of table locks if
InnoDB
[436], and the MySQL layer above it knows about row-level locks. Otherwise,
0
deadlocks where a table lock set by a MySQL
engine other than
innodb_lock_wait_timeout
When
InnoDB
released. However, if just a single SQL statement is rolled back as a result of an error, some of the
locks set by the statement may be preserved. This happens because
format such that it cannot know afterward which lock was set by which statement.
14.2.7.9. How to Cope with Deadlocks
Deadlocks are a classic problem in transactional databases, but they are not dangerous unless
they are so frequent that you cannot run certain transactions at all. Normally, you must write your
applications so that they are always prepared to re-issue a transaction if it gets rolled back because of
a deadlock.
uses automatic row-level locking. You can get deadlocks even in the case of transactions
InnoDB
that just insert or delete a single row. That is because these operations are not really "atomic"; they
automatically set locks on the (possibly several) index records of the row inserted or deleted.
You can cope with deadlocks and reduce the likelihood of their occurrence with the following
techniques:
• Use
SHOW ENGINE INNODB STATUS
you to tune your application to avoid deadlocks.
• Always be prepared to re-issue a transaction if it fails due to deadlock. Deadlocks are not dangerous.
Just try again.
• Commit your transactions often. Small transactions are less prone to collision.
• If you are using locking reads
MODE), try using a lower isolation level such as
• Access your tables and rows in a fixed order. Then transactions form well-defined queues and do not
deadlock.
The Transaction Model and Locking
InnoDB
Rollback". See also Section 14.2.13, "Limits on
Handling".
Section 13.3.3, "Statements That Cause an Implicit
tries to pick small transactions to roll back, where the size of a transaction
InnoDB
innodb_table_locks = 1
is involved. You must resolve these situations by setting the value of the
InnoDB
[1244]
performs a complete rollback of a transaction, all locks set by the transaction are
(SELECT ... FOR UPDATE
statement or a lock set by a storage
LOCK TABLES
system variable.
to determine the cause of the latest deadlock. That can help
or
READ COMMITTED
1274
Section 14.2.7.8, "Deadlock
Tables".
InnoDB
before executing the
COMMIT
Commit".
(the default) and
autocommit =
InnoDB
stores row locks in a
InnoDB
SELECT ... LOCK IN SHARE
[1121].
Section 14.2.11,
cannot detect