Table Locking Issues inserted at the end of the data file. In this case, you can freely mix concurrent  INSERT  and  SELECT statements for a  MyISAM  table without locks. That is, you can insert rows into a  MyISAM  table 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. To control this behavior, use the concurrent_insert  system variable. See Section 8.11.3, “Concurrent Inserts” . If you acquire a table lock explicitly with  LOCK TABLES , you can request a  READ LOCAL  lock rather than a READ  lock to enable other sessions to perform concurrent inserts while you have the table locked. To perform many  INSERT  and  SELECT  operations on a table  t1  when concurrent inserts are not possible, you can insert rows into a temporary table  temp_t1  and update the real table with the rows from the temporary table: Generally, table locks are superior to row-level locks in the following cases: With higher-level locks, you can more easily tune applications by supporting locks of different types, because the lock overhead is less than for row-level locks. Options other than row-level locking: InnoDB  tables use row-level locking so that multiple sessions and applications can read from and write to the same table simultaneously, without making each other wait or producing inconsistent results. For this storage engine, avoid using the  LOCK TABLES  statement, because it does not offer any extra protection, 8.11.2 Table Locking Issues •Versioning (such as that used in MySQL for concurrent inserts) where it is possible to have one writer at the same time as many readers. This means that the database or table supports different views for the data depending on when access begins. Other common terms for this are “time travel,”  “copy on write,” or “copy on demand.” •Copy on demand is in many cases superior to row-level locking. However, in the worst case, it can use much more memory than using normal locks. •Instead of using row-level locks, you can employ application-level locks, such as those provided by GET_LOCK()  and  RELEASE_LOCK()  in MySQL. These are advisory locks, so they work only with applications that cooperate with each other. See Section 12.15, “Locking Functions” . •Many scans or  GROUP BY  operations on the entire table without any writers. • SELECT  combined with concurrent  INSERT  statements, and very few  UPDATE  or  DELETE  statements. •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: •Most statements for the table are reads. Choosing the Type of Locking 1824 UPDATE  tbl_name  SET  column = value  WHERE  unique_key_col = key_value ; DELETE FROM  tbl_name  WHERE  unique_key_col = key_value ; mysql>  LOCK TABLES t1 WRITE, temp_t1 WRITE; mysql>  INSERT INTO t1 SELECT * FROM temp_t1; mysql>  DELETE FROM temp_t1; mysql>  UNLOCK TABLES;