SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded 解决思路

SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction
MySQL有时会报这种延时的异常。
一、问题分析
经过对网上相关问题的搜索,总结了解决这种问题的分析思路:

首先,表象上,是SQL执行时间太长,导致超过数据库设置的默认延时时长。
如果经过分析,确实由于有些事务的延时太大导致的。分析思路和步骤是:

步骤1:查看影响的table
步骤2:获取所有附加锁的种类和其他互斥信息

分析数据:
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 7805377
Mutex spin waits 0, rounds 11487096053, OS waits 7756855
RW-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 499
mysql tables in use 1, locked 1
14 lock struct(s), heap size 3024, 8 row lock(s), undo log entries 1
MySQL thread id 3686635, query id 124164167 10.64.89.145 viget updating
DELETE 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 620783814
Purge done for trx's n:o < 0 620783800 undo n:o < 0 0
History list length 35
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0 0, not started, process no 29956, OS thread id 1192212800
MySQL thread id 5341758, query id 189708501 127.0.0.1 lwdba
show innodb status
---TRANSACTION 0 620783788, not started, process no 29956, OS thread id 1196472640
MySQL thread id 5341773, query id 189708353 10.64.89.143 viget
---TRANSACTION 0 0, not started, process no 29956, OS thread id 1223895360
MySQL thread id 5341667, query id 189706152 10.64.89.145 viget
---TRANSACTION 0 0, not started, process no 29956, OS thread id 1227888960
MySQL thread id 5341556, query id 189699857 172.16.135.63 lwdba
---TRANSACTION 0 620781112, not started, process no 29956, OS thread id 1222297920
MySQL thread id 5341511, query id 189696265 10.64.89.143 viget
---TRANSACTION 0 620783736, not started, process no 29956, OS thread id 1229752640
MySQL thread id 5339005, query id 189707998 10.64.89.144 viget
---TRANSACTION 0 620783785, not started, process no 29956, OS thread id 1198602560
MySQL thread id 5337583, query id 189708349 10.64.89.145 viget
---TRANSACTION 0 620783469, not started, process no 29956, OS thread id 1224161600
MySQL thread id 5333500, query id 189708478 10.64.89.144 viget
---TRANSACTION 0 620781240, not started, process no 29956, OS thread id 1198336320
MySQL thread id 5324256, query id 189708493 10.64.89.145 viget
---TRANSACTION 0 617458223, not started, process no 29956, OS thread id 1195141440
MySQL 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: 0
Pending flushes (fsync) log: 0; buffer pool: 0
519878 OS file reads, 18962880 OS file writes, 13349046 OS fsyncs
0.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 merges
Hash 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 1235093534
Log flushed up to   28 1235093534
Last checkpoint at  28 1235091275
0 pending log writes, 0 pending chkp writes
12262564 log i/o's done, 3.25 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 18909316674; in additional pool allocated 1048576
Dictionary memory allocated 2019632
Buffer pool size   1048576
Free buffers       175763
Database pages     837653
Modified db pages  6
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages read 770138, created 108485, written 7795318
0.00 reads/s, 0.00 creates/s, 4.25 writes/s
Buffer pool hit rate 1000 / 1000
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
1 read views open inside InnoDB
Main thread process no. 29956, id 1185823040, state: sleeping
Number of rows inserted 6453767, updated 4602534, deleted 3638793, read 388349505551
0.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)

二、解决方案
调整 lock wait timeout value
调整参数:innodb_lock_wait_timeout,默认是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)

可以将这个参数调高:
vim /etc/my.cnf

[mysqld]
innodb_lock_wait_timeout=120

然后重启MySQL.
如果不能重启MySQL,可以设置全局变量即时生效。
SET GLOBAL innodb_lock_wait_timeout = 120; 

也可以设置只对当前session生效:
SET innodb_lock_wait_timeout = 120; 

其次,如果通过上述的方式解决不了,可以关注一下是否存在死锁现象。

文章参考:Stack Overflow
 

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: 在数据库中执行操作时,如果遇到“SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restart”错误提示,通常是由于一个事务等待锁超过了数据库的默认超时时间。 这个错误通常出现在并发环境下,当多个事务同时对同一数据进行修改时,会出现锁争用的情况。当一个事务正在修改某个数据时,它会锁定这个数据,以防止其他事务同时进行修改。如果一个事务等待锁的时间超过了数据库设置的默认超时时间,就会触发该错误提示。 为了解决这个问题,可以采取以下几种方法: 1. 增加超时时间:可以通过修改数据库的配置参数来增加锁等待超时时间,但这可能会对系统整体性能产生影响,因此需要谨慎使用。 2. 优化查询:可以通过优化SQL语句、创建合理的索引等方式,减少锁的等待时间,提高查询性能。 3. 分批处理:如果涉及到大量数据的修改操作,可以考虑将数据分批处理,以减少锁冲突的可能性。 4. 使用合适的事务隔离级别:不同的事务隔离级别对数据锁定的方式不同,选择合适的事务隔离级别也可以减少锁冲突的可能性。 总之,解决SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restart”错误需要深入了解数据库的性能瓶颈和事务处理,并采取相应的优化措施来避免或减少锁冲突的发生。 ### 回答2: 该错误表示在执行SQL语句时,发生了锁等待超时错误。这通常是由于一个事务请求另一个事务持有的锁导致的。当在某个事务中持有了一个资源(例如表、行或其他对象)的锁,并且另一个事务想要执行与该资源有关的操作时,就会发生锁等待。 这种情况下,如果等待的时间超过了设置的超时时间,就会触发该错误,并建议尝试重新启动(restart)。意思是建议重新启动数据库服务,以解决锁等待超时的问题。 要解决这个问题,可以尝试以下方法: 1. 增加超时时间:可以尝试增加超时时间的设置,以提供更长的等待时间,从而允许锁等待更久。 2. 优化操作:检查数据库操作的性能,优化查询语句或事务操作,减少对资源的锁定时间,以减少锁等待的可能性。 3. 检查并发性设置:确保数据库的并发性设置适合当前的负载。如果负载过重,可以考虑增加硬件资源或优化数据库配置。 4. 分离长时间运行的事务:如果发现某个事务需要占用资源的时间过长,可以尝试将其分解为更小的事务,以减少单个事务的锁定时间。 总之,SQLSTATE [HY000]: general error: 1205 lock wait timeout exceeded; try restart是由于锁等待超时引起的错误,常见于事务间发生锁冲突的情况。通过增加超时时间、优化操作、检查并发性设置和分离长时间运行的事务等方法,可以解决这个错误。 ### 回答3: 出现这个错误原因是在执行 SQL 语句时,某个线程发现所需的锁资源被其他线程占用,无法立即获取,等待一段时间后超时。这个错误告诉我们尝试重新启动可以尝试解决问题。 解决这个问题可以尝试以下几种方案: 1. 增加锁超时时间:在配置文件中增加 innodb_lock_wait_timeout 的值,以确保等待锁的时间更长。如将其设置为60秒或更高。 2. 优化查询性能:考虑对查询进行优化以减少对锁资源的需求。可以通过增加适当的索引、优化 SQL 查询语句或者分解事务等方式来改善查询性能。 3. 减少并发操作:如果系统并发操作较大,可以考虑减少同时执行的事务数,通过控制并发度来降低锁等待的概率。 4. 检查死锁:查看是否存在死锁情况,如果有的话需要解决死锁问题。 5. 检查服务器负载:如果服务器负载过高,可能会导致锁等待增加,检查服务器资源是否足够,或者增加服务器的性能配置。 总之,解决这个问题需要综合考虑锁配置、查询性能、并发操作等因素,找到合适的方式来进行调整。如果以上方法无法解决问题,可以通过数据库日志或者咨询数据库管理员进行进一步的分析和解决
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值