•Start mysqld  with a low value for the max_write_lock_count  system variable to force MySQL to temporarily elevate the priority of all SELECT  statements that are waiting for a table after a specific number of write locks to the table occur (for example, for insert operations). This permits read locks after a certain number of write locks. 

•If you have problems with mixed SELECT  and DELETE  statements, the LIMIT  option to DELETE  may help. See Section 13.2.2, “DELETE Statement” . 

•Using SQL_BUFFER_RESULT  with SELECT  statements can help to make the duration of table locks shorter. See Section 13.2.10, “SELECT Statement” . 

•Splitting table contents into separate tables may help, by allowing queries to run against columns in one table, while updates are confined to columns in a different table. 

•You could 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. 

## 8.11.3 Concurrent Inserts 

The MyISAM  storage engine supports concurrent inserts to reduce contention between readers and writers for a given table: If a MyISAM  table has no holes in the data file (deleted rows in the middle), an INSERT statement can be executed to add rows to the end of the table at the same time that SELECT  statements are reading rows from the table. If there are multiple INSERT  statements, they are queued and performed in sequence, concurrently with the SELECT  statements. The results of a concurrent INSERT  may not be visible immediately. 

The concurrent_insert  system variable can be set to modify the concurrent-insert processing. By default, the variable is set to AUTO  (or 1) and concurrent inserts are handled as just described. If concurrent_insert  is set to NEVER  (or 0), concurrent inserts are disabled. If the variable is set to ALWAYS  (or 2), concurrent inserts at the end of the table are permitted even for tables that have deleted rows. See also the description of the concurrent_insert  system variable. 

If you are using the binary log, concurrent inserts are converted to normal inserts for CREATE ... SELECT  or INSERT ... SELECT  statements. This is done to ensure that you can re-create an exact copy of your tables by applying the log during a backup operation. See Section 5.4.4, “The Binary Log” . In addition, for those statements a read lock is placed on the selected-from table such that inserts into that table are blocked. The effect is that concurrent inserts for that table must wait as well. 

With LOAD DATA , if you specify CONCURRENT  with a MyISAM  table that satisfies the condition for concurrent inserts (that is, it contains no free blocks in the middle), other sessions can retrieve data from the table while LOAD DATA  is executing. Use of the CONCURRENT  option affects the performance of LOAD DATA  a bit, even if no other session is using the table at the same time. 

If you specify HIGH_PRIORITY , it overrides the effect of the --low-priority-updates  option if the server was started with that option. It also causes concurrent inserts not to be used. 

For LOCK TABLE , the difference between READ LOCAL  and READ  is that READ LOCAL  permits nonconflicting INSERT  statements (concurrent inserts) to execute while the lock is held. However, this cannot be used if you are going to manipulate the database using processes external to the server while you hold the lock. 

## 8.11.4 Metadata Locking 

MySQL uses metadata locking to manage concurrent access to database objects and to ensure data consistency. Metadata locking applies not just to tables, but also to schemas, stored programs (procedures, functions, triggers, scheduled events), tablespaces, user locks acquired with the 

