我的MySQL死锁场景 - 需要建议

时间:2011-04-11 02:19:08

标签: php mysql codeigniter database-deadlocks

我需要专家建议。

背景 PHP / Codeigniter 库MySQLi Innodb表 - fares_table 存储过程

后端 - 编写一个cronjob php脚本,每隔几分钟将数据(从服务)插入/更新到fares_table。 (正常的SQL查询)

前端 - 用户将能够读取这些数据 (查询是以存储过程形式编写的,因为它涉及连接许多表,因此我的存储过程从fares_table的select语句创建临时表并连接到其他表)

问题

Deadlock found when trying to get lock; try restarting transaction

如果用户碰巧在fares_table正在更新/插入时偶然发现前端,则可能发生死锁。死锁发生在更新语句

死锁是由存储过程尝试等待锁释放时尝试使用fares_table中的select语句创建临时表引起的 而后端执行插入或更新试图等待锁定释放。

LATEST DETECTED DEADLOCK
------------------------
110408  9:05:45
*** (1) TRANSACTION:
TRANSACTION 0 203543446, ACTIVE 0 sec, OS thread id 6584 fetching rows
mysql tables in use 2, locked 2
LOCK WAIT 761 lock struct(s), heap size 60736, 30170 row lock(s)
MySQL thread id 86268, query id 135039790 XXXXXXX Copying to t
CREATE TEMPORARY TABLE tmp_tb1 AS SELECT MIN( fare ) as cheapest_fare,flighttype origin,destination ....
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 18433 n bits 240 index `PRIMARY` of table `db_name`.`fares_table`
Record lock, heap no 85 PHYSICAL RECORD: n_fields 18; compact format; info bits 0
0: len 4; hex 8025d996; asc  %  ;; 1: len 6; hex 00000c21d3a9; asc    !  ;; 2: len 7; hex 0000000b031

*** (2) TRANSACTION:
TRANSACTION 0 203543465, ACTIVE 0 sec, OS thread id 3080 updating or deleting, thread declared inside
mysql tables in use 1, locked 1
3 lock struct(s), heap size 320, 2 row lock(s), undo log entries 1
MySQL thread id 85631, query id 135039816 XXXXX Updating
UPDATE `fares_table` SET `fare` = 2552.85, `currency` = 'AUD'..
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 0 page no 18433 n bits 240 index `PRIMARY` of table `db_name`.`fares_table`
Record lock, heap no 85 PHYSICAL RECORD: n_fields 18; compact format; info bits 0
0: len 4; hex 8025d996; asc  %  ;; 1: len 6; hex 00000c21d3a9; asc    !  ;; 2: len 7; hex 0000000b031

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 2086 n bits 600 index `flighttype_idx` of table `db_name`.`fares_table`
Record lock, heap no 218 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 7; hex 4f6e6520776179; asc One way;; 1: len 3; hex 424e45; asc BNE;; 2: len 8; hex 8000124a588

*** WE ROLL BACK TRANSACTION (2)

我的临时修复

捕获数据库错误1213并重试更新查询。它现在有效,但我想找到一个更好的解决方案来防止死锁。 任何专业建议?

如何更改顺序以防止死锁或重复flighttype_idx的索引有帮助?

1 个答案:

答案 0 :(得分:0)

由于创建临时表的查询由于聚合函数MIN(fare)而需要实质上锁定表的主要部分,并且票价更新需要等待它完成,因此没有简单的重新排序可以解决僵局。

最好通过显式锁定机制来包围争用,可能只是为了这个目的在锁定表上,而不是让事务竞争然后必须回滚。特别是,创建表语句cannot be rolled back,看起来很奇怪。请参阅LOCK TABLE documentation

要整齐地实施,请将票价更新语句移动到存储过程中,让票价更新和临时表创建存储过程循环检查并设置锁定,完成工作,然后解锁。

相关问题