Oracle 5.0 Reference Manual page 730

You can analyze the table lock contention on your system by checking the
Table_locks_immediate
the number of times that requests for table locks could be granted immediately and the number that
had to wait, respectively:
mysql> SHOW STATUS LIKE 'Table%';
+-----------------------+---------+
| Variable_name
+-----------------------+---------+
| Table_locks_immediate | 1151552 |
| Table_locks_waited
+-----------------------+---------+
The storage engine supports concurrent inserts to reduce contention between readers and
MyISAM
writers for a given table: If a
always inserted at the end of the data file. In this case, you can freely mix concurrent
statements for a
SELECT
at the same time other clients are reading from it. Holes can result from rows having been deleted
from or updated in the middle of the table. If there are holes, concurrent inserts are disabled but are
enabled again automatically when all holes have been filled with new data. This behavior is altered by
the
concurrent_insert
If you acquire a table lock explicitly with
than a lock to enable other sessions to perform concurrent inserts while you have the table
READ
locked.
To perform many
INSERT
are not possible, you can insert rows into a temporary table
with the rows from the temporary table periodically. This can be done with the following code:
mysql> LOCK TABLES real_table WRITE, temp_table WRITE;
mysql> INSERT INTO real_table SELECT * FROM temp_table;
mysql> DELETE FROM temp_table;
mysql> UNLOCK TABLES;
uses row locks and
InnoDB
because they automatically acquire locks during the processing of SQL statements, not at the start of
the transaction.
Advantages of row-level locking:
• Fewer lock conflicts when different sessions access different rows
• Fewer changes for rollbacks
• Possible to lock a single row for a long time
Disadvantages of row-level locking:
• Requires more memory than page-level or table-level locks
• Slower than page-level or table-level locks when used on a large part of the table because you must
acquire many more locks
• Slower than other locks if you often do
must scan the entire table frequently
Generally, table locks are superior to page-level or row-level locks in the following cases:
• Most statements for the table are reads
• Statements for the table are a mix of reads and writes, where writes are updates or deletes for a
single row that can be fetched with one key read:
Internal Locking Methods
[533] and
Table_locks_waited
| Value |
| 15324 |
table has no free blocks in the middle of the data file, rows are
MyISAM
table without locks. That is, you can insert rows into a
MyISAM
[445] system variable. See
TABLES, you can request a
LOCK
and operations on a table
SELECT
uses page locks. Deadlocks are possible for these storage engines
BDB
GROUP BY
710
[533] status variables, which indicate
Section 8.7.3, "Concurrent
READ LOCAL
real_table
and update the real table
temp_table
operations on a large part of the data or if you
and
INSERT
table
MyISAM
Inserts".
lock rather
when concurrent inserts