LOCK TABLES and UNLOCK TABLES Statements Tables in the  performance_schema  database cannot be locked with  LOCK TABLES , except the setup_ xxx  tables. The following statements are prohibited while a  LOCK TABLES  statement is in effect:  CREATE TABLE , CREATE TABLE ... LIKE ,  CREATE VIEW ,  DROP VIEW , and DDL statements on stored functions and procedures and events. For some operations, system tables in the  mysql  database must be accessed. For example, the  HELP statement requires the contents of the server-side help tables, and  CONVERT_TZ()  might need to read the time zone tables. The server implicitly locks the system tables for reading as necessary so that you need not lock them explicitly. These tables are treated as just described: If you want to explicitly place a  WRITE  lock on any of those tables with a  LOCK TABLES  statement, the table must be the only one locked; no other table can be locked with the same statement. Normally, you do not need to lock tables, because all single  UPDATE  statements are atomic; no other session can interfere with any other currently executing SQL statement. However, there are a few cases when locking tables may provide an advantage: The downside to locking the tables is that no session can update a  READ -locked table (including the one holding the lock) and no session can access a  WRITE -locked table other than the one holding the lock. Without  LOCK TABLES , it is possible that another session might insert a new row in the  trans  table between execution of the  SELECT  and  UPDATE  statements. You can avoid using  LOCK TABLES  in many cases by using relative updates ( UPDATE customer SET value = value + new_value ) or the  LAST_INSERT_ID()  function. You can also avoid locking tables in some cases by using the user-level advisory lock functions GET_LOCK()  and  RELEASE_LOCK() . These locks are saved in a hash table in the server and implemented with  pthread_mutex_lock()  and  pthread_mutex_unlock()  for high speed. See Section 12.15, “Locking Functions” . 2731 •If you are going to run many operations on a set of  MyISAM  tables, it is much faster to lock the tables you are going to use. Locking  MyISAM  tables speeds up inserting, updating, or deleting on them because MySQL does not flush the key cache for the locked tables until  UNLOCK TABLES  is called. Normally, the key cache is flushed after each SQL statement. •If you are using tables for a nontransactional storage engine, you must use  LOCK TABLES  if you want to ensure that no other session modifies the tables between a  SELECT  and an  UPDATE . The example shown here requires  LOCK TABLES  to execute safely: LOCK TABLES trans READ, customer WRITE; SELECT SUM(value) FROM trans WHERE customer_id= some_id ; UPDATE customer SET total_value= sum_from_previous_statement WHERE customer_id= some_id ; UNLOCK TABLES; mysql.help_category mysql.help_keyword mysql.help_relation mysql.help_topic mysql.time_zone mysql.time_zone_leap_second mysql.time_zone_name mysql.time_zone_transition mysql.time_zone_transition_type