How to debug Lock wait timeout exceeded on MySQL?

What gives this away is the word transaction. It is evident by the statement that the query was attempting to change at least one row in one or more InnoDB tables.

Since you know the query, all the tables being accessed are candidates for being the culprit.

From there, you should be able to run SHOW ENGINE INNODB STATUS\G

You should be able to see the affected table(s)

You get all kinds of additional Locking and Mutex Information.

Here is a sample from one of my clients:

mysql> show engine innodb status\G*************************** 1. row ***************************  Type: InnoDB  Name:Status:=====================================110514 19:44:14 INNODB MONITOR OUTPUT=====================================Per second averages calculated from the last 4 seconds----------SEMAPHORES----------OS WAIT ARRAY INFO: reservation count 9014315, signal count 7805377Mutex spin waits 0, rounds 11487096053, OS waits 7756855RW-shared spins 722142, OS waits 211221; RW-excl spins 787046, OS waits 39353------------------------LATEST FOREIGN KEY ERROR------------------------110507 21:41:35 Transaction:TRANSACTION 0 606162814, ACTIVE 0 sec, process no 29956, OS thread id 1223895360 updating or deleting, thread declared inside InnoDB 499mysql tables in use 1, locked 114 lock struct(s), heap size 3024, 8 row lock(s), undo log entries 1MySQL thread id 3686635, query id 124164167 10.64.89.145 viget updatingDELETE FROM file WHERE file_id in ('6dbafa39-7f00-0001-51f2-412a450be5cc' )Foreign key constraint fails for table `backoffice`.`attachment`:,  CONSTRAINT `attachment_ibfk_2` FOREIGN KEY (`file_id`) REFERENCES `file` (`file_id`)Trying to delete or update in parent table, in index `PRIMARY` tuple:DATA TUPLE: 17 fields; 0: len 36; hex 36646261666133392d376630302d303030312d353166322d343132613435306265356363; asc 6dbafa39-7f00-0001-51f2-412a450be5cc;; 1: len 6; hex 000024214f7e; asc   $!O~;; 2: len 7; hex 000000400217bc; asc    @   ;; 3: len 2; hex 03e9; asc   ;; 4: len 2; hex 03e8; asc   ;; 5: len 36; hex 65666635323863622d376630302d303030312d336632662d353239626433653361333032; asc eff528cb-7f00-0001-3f2f-529bd3e3a302;; 6: len 40; hex 36646234376337652d376630302d303030312d353166322d3431326132346664656366352e6d7033; asc 6db47c7e-7f00-0001-51f2-412a24fdecf5.mp3;; 7: len 21; hex 416e67656c73204e6f7720436f6e666572656e6365; asc Angels Now Conference;; 8: len 34; hex 416e67656c73204e6f7720436f6e666572656e6365204a756c7920392c2032303131; asc Angels Now Conference July 9, 2011;; 9: len 1; hex 80; asc  ;; 10: len 8; hex 8000124a5262bdf4; asc    JRb  ;; 11: len 8; hex 8000124a57669dc3; asc    JWf  ;; 12: SQL NULL; 13: len 5; hex 8000012200; asc    " ;; 14: len 1; hex 80; asc  ;; 15: len 2; hex 83e8; asc   ;; 16: len 4; hex 8000000a; asc     ;;But in child table `backoffice`.`attachment`, in index `PRIMARY`, there is a record:PHYSICAL RECORD: n_fields 6; compact format; info bits 0 0: len 30; hex 36646261666133392d376630302d303030312d353166322d343132613435; asc 6dbafa39-7f00-0001-51f2-412a45;...(truncated); 1: len 30; hex 38666164663561652d376630302d303030312d326436612d636164326361; asc 8fadf5ae-7f00-0001-2d6a-cad2ca;...(truncated); 2: len 6; hex 00002297b3ff; asc   "   ;; 3: len 7; hex 80000040070110; asc    @   ;; 4: len 2; hex 0000; asc   ;; 5: len 30; hex 416e67656c73204e6f7720436f6e666572656e636520446f63756d656e74; asc Angels Now Conference Document;;------------TRANSACTIONS------------Trx id counter 0 620783814Purge done for trx's n:o < 0 620783800 undo n:o < 0 0History list length 35LIST OF TRANSACTIONS FOR EACH SESSION:---TRANSACTION 0 0, not started, process no 29956, OS thread id 1192212800MySQL thread id 5341758, query id 189708501 127.0.0.1 lwdbashow innodb status---TRANSACTION 0 620783788, not started, process no 29956, OS thread id 1196472640MySQL thread id 5341773, query id 189708353 10.64.89.143 viget---TRANSACTION 0 0, not started, process no 29956, OS thread id 1223895360MySQL thread id 5341667, query id 189706152 10.64.89.145 viget---TRANSACTION 0 0, not started, process no 29956, OS thread id 1227888960MySQL thread id 5341556, query id 189699857 172.16.135.63 lwdba---TRANSACTION 0 620781112, not started, process no 29956, OS thread id 1222297920MySQL thread id 5341511, query id 189696265 10.64.89.143 viget---TRANSACTION 0 620783736, not started, process no 29956, OS thread id 1229752640MySQL thread id 5339005, query id 189707998 10.64.89.144 viget---TRANSACTION 0 620783785, not started, process no 29956, OS thread id 1198602560MySQL thread id 5337583, query id 189708349 10.64.89.145 viget---TRANSACTION 0 620783469, not started, process no 29956, OS thread id 1224161600MySQL thread id 5333500, query id 189708478 10.64.89.144 viget---TRANSACTION 0 620781240, not started, process no 29956, OS thread id 1198336320MySQL thread id 5324256, query id 189708493 10.64.89.145 viget---TRANSACTION 0 617458223, not started, process no 29956, OS thread id 1195141440MySQL thread id 736, query id 175038790 Has read all relay log; waiting for the slave I/O thread to update it--------FILE I/O--------I/O thread 0 state: waiting for i/o request (insert buffer thread)I/O thread 1 state: waiting for i/o request (log thread)I/O thread 2 state: waiting for i/o request (read thread)I/O thread 3 state: waiting for i/o request (write thread)Pending normal aio reads: 0, aio writes: 0, ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0Pending flushes (fsync) log: 0; buffer pool: 0519878 OS file reads, 18962880 OS file writes, 13349046 OS fsyncs0.00 reads/s, 0 avg bytes/read, 6.25 writes/s, 4.50 fsyncs/s-------------------------------------INSERT BUFFER AND ADAPTIVE HASH INDEX-------------------------------------Ibuf: size 1, free list len 1190, seg size 1192,174800 inserts, 174800 merged recs, 54439 mergesHash table size 35401603, node heap has 35160 buffer(s)0.50 hash searches/s, 11.75 non-hash searches/s---LOG---Log sequence number 28 1235093534Log flushed up to   28 1235093534Last checkpoint at  28 12350912750 pending log writes, 0 pending chkp writes12262564 log i/o's done, 3.25 log i/o's/second----------------------BUFFER POOL AND MEMORY----------------------Total memory allocated 18909316674; in additional pool allocated 1048576Dictionary memory allocated 2019632Buffer pool size   1048576Free buffers       175763Database pages     837653Modified db pages  6Pending reads 0Pending writes: LRU 0, flush list 0, single page 0Pages read 770138, created 108485, written 77953180.00 reads/s, 0.00 creates/s, 4.25 writes/sBuffer pool hit rate 1000 / 1000--------------ROW OPERATIONS--------------0 queries inside InnoDB, 0 queries in queue1 read views open inside InnoDBMain thread process no. 29956, id 1185823040, state: sleepingNumber of rows inserted 6453767, updated 4602534, deleted 3638793, read 3883495055510.25 inserts/s, 1.25 updates/s, 0.00 deletes/s, 2.75 reads/s----------------------------END OF INNODB MONITOR OUTPUT============================1 row in set, 1 warning (0.00 sec)

You should consider increasing the lock wait timeout value for InnoDB by setting the innodb_lock_wait_timeout, default is 50 sec

mysql> show variables like 'innodb_lock_wait_timeout';+--------------------------+-------+| Variable_name            | Value |+--------------------------+-------+| innodb_lock_wait_timeout | 50    |+--------------------------+-------+1 row in set (0.01 sec)

You can set it to higher value in /etc/my.cnf permanently with this line

[mysqld]innodb_lock_wait_timeout=120

and restart mysql. If you cannot restart mysql at this time, run this:

SET GLOBAL innodb_lock_wait_timeout = 120; 

You could also just set it for the duration of your session

SET innodb_lock_wait_timeout = 120; 

followed by your query

As someone mentioned in one of the many SO threads concerning this problem: Sometimes the process that has locked the table shows up as sleeping in the processlist! I was tearing my hair out until I killed all the sleeping threads that were open in the database in question (none were active at the time). That finally unlocked the table and let the update query run.

The commenter said something akin to "Sometimes a MySQL thread locks a table, then sleeps while it waits for something non-MySQL-related to happen."

After re-re-reviewing the show engine innodb status log (once I'd tracked down the client responsible for the lock), I noticed the stuck thread in question was listed at the very bottom of the transaction list, beneath the active queries that were about to error out because of the frozen lock:

---------------------TRANSACTION 2744943820, ACTIVE 1154 sec(!!)2 lock struct(s), heap size 376, 2 row lock(s), undo log entries 1MySQL thread id 276558, OS thread handle 0x7f93762e7710, query id 59264109 [ip] [database] cleaning upTrx read view will not see trx with id >= 2744943821, sees < 2744943821

(unsure if the "Trx read view" message is related to the frozen lock, but unlike the other active transactions, this one does not show up with the query that was issued and instead claims the transaction is "cleaning up," yet has multiple row locks)

The moral of the story is that a transaction can be active even though the thread is sleeping.

The more contention you have, the greater the chance of deadlocks, which a DB engine will resolve by time-outing one of the deadlocked transactions.

Also, long-running transactions that have modified (e.g. UPDATE or DELETE) a large number of entries are more likely to generate conflicts with other transactions.

Although InnoDB MVCC, you can still request explicit locks using the FOR UPDATE clause. However, unlike other popular DBs (Oracle, MSSQL, PostgreSQL, DB2), MySQL uses REPEATABLE_READ as the default isolation level.

Now, the locks that you acquired (either by modifying rows or using explicit locking) are held for the duration of the currently running transaction. If you want a good explanation of the difference between REPEATABLE_READ and READ COMMITTED in regards to locking, please read this Percona article.

In REPEATABLE READ every lock acquired during a transaction is heldfor the duration of the transaction.

In READ COMMITTED the locks that did not match the scan are released after the STATEMENT completes.

...

This means that in READ COMMITTED other transactions are free to update rows that they would not have been able to update (in REPEATABLE READ) once the UPDATE statement completes.

Therefore: The more restrictive the isolation level (REPEATABLE_READ, SERIALIZABLE) the greater the chance of deadlock. This is not an issue "per se", it's a trade-off.

You can get very good results with READ_COMMITED, as you need application-level lost update prevention when using logical transactions that span over multiple HTTP requests. The optimistic locking approach targets lost updates that might happen even if you use the SERIALIZABLE isolation level while reducing the lock contention by allowing you to use READ_COMMITED.