You can find a discussion about different locking methods in the appendix. See section E.4 Locking methods.
All locking in MySQL is deadlock-free, except for InnoDB
and
BDB
type tables.
This is managed by always
requesting all needed locks at once at the beginning of a query and always
locking the tables in the same order.
InnoDB
type tables automatically acquire their row locks and
BDB
type tables
their page locks during the processing of SQL statements, not at the start
of the transaction.
The locking method MySQL uses for WRITE
locks works as follows:
The locking method MySQL uses for READ
locks works as follows:
When a lock is released, the lock is made available to the threads in the write lock queue, then to the threads in the read lock queue.
This means that if you have many updates on a table, SELECT
statements will wait until there are no more updates.
To work around this for the case where you want to do many INSERT
and
SELECT
operations on a table, you can insert rows in a temporary
table and update the real table with the records from the temporary table
once in a while.
This can be done with the following code:
mysql> LOCK TABLES real_table WRITE, insert_table WRITE; mysql> INSERT INTO real_table SELECT * FROM insert_table; mysql> TRUNCATE TABLE insert_table; mysql> UNLOCK TABLES;
You can use the LOW_PRIORITY
options with INSERT
,
UPDATE
or DELETE
or HIGH_PRIORITY
with
SELECT
if you want to prioritise retrieval in some specific
cases. You can also start mysqld
with --low-priority-updates
to get the same behaveour.
Using SQL_BUFFER_RESULT
can also help making table locks shorter.
See section 6.4.1 SELECT
Syntax.
You could also change the locking code in `mysys/thr_lock.c' to use a single queue. In this case, write locks and read locks would have the same priority, which might help some applications.