2012-01-21 17 views
0

MySQLのデッドロックエラーが発生するコードセクションがあります。基本的には、フィールドを取得するためにselectを実行しています。そのフィールドに応じて、同じレコードのカウンタをインクリメントするか、別のフィールドを挿入します。このコードは他のいくつかのシステムによって呼び出されています。 (PHP/ZendFramework/MySQLの)MySQLのデッドロックの問題(PHP/MYSQL)

$db = $dbMgr->GetConnection(); // gets a connection & starts transaction 

// get a count field from the database... 
$result = $db->query("SELECT status_id,status,count FROM status WHERE company_id={$companyId} AND probe_id={$probeId} AND host_id={$hostId} ORDER BY timestamp DESC LIMIT 1;"); 

// do some stuff with the data.. maybe there is no current record, modify to use insert logic below 

// only process if we have a command 
if ($newStatus != $lastStatus) { 
    $record = array(); 
    $record["status"] = $newStatus; 
    $record["count"] = 1; 
    $db->insert('status', $record); // INSERT THE RECORD 
    $statusId = $db->lastInsertId(); 
} else { 
    $db->query("UPDATE status SET count=count+1,last_updated=".time()." WHERE status_id={$lastRecord} LIMIT 1;"); // UPDATE THE RECORD 
    $statusId = $lastRecord; 
} 

$dbMgr->commit(); // commits on success, rolls back on failure 

[編集]これは役立つかもしれないと思った:

------------------------ 
LATEST DETECTED DEADLOCK 
------------------------ 
120121 16:12:02 
*** (1) TRANSACTION: 
TRANSACTION A42EF1D, ACTIVE 0 sec, process no 30952, OS thread id 1234467136 starting index read 
mysql tables in use 1, locked 1 
LOCK WAIT 3 lock struct(s), heap size 1248, 39 row lock(s) 
MySQL thread id 77901288, query id 705153914 ip-10-36-78-178.ec2.internal 10.36.78.178 root Sending data 
SELECT qid,command,content_url,nextrundate,locked_until,data FROM items WHERE command='NOTIFY' AND status='PENDING' AND nextrundate <= 1327162322 AND 1327162322 > locked_until ORDER BY nextrundate LIMIT 150 FOR UPDATE 
*** (1) WAITING FOR THIS LOCK TO BE GRANTED: 
RECORD LOCKS space id 404 page no 1223 n bits 232 index `PRIMARY` of table `queue`.`items` trx id A42EF1D lock_mode X locks rec but not gap waiting 
Record lock, heap no 159 PHYSICAL RECORD: n_fields 12; compact format; info bits 32 
0: len 8; hex 00000000006fe5c4; asc  o ;; 
1: len 6; hex 00000a42ef1a; asc B ;; 
2: len 7; hex 00000000390110; asc  9 ;; 
3: len 1; hex 81; asc ;; 
4: len 11; hex 50524f42455f4556454e54; asc PROBE_EVENT;; 
5: len 15; hex 352f3934302f3934302e70726f6265; asc 5/940/940.probe;; 
6: len 15; hex 50524f42455f4556454e545f393430; asc PROBE_EVENT_940;; 
7: len 4; hex 4f1ae3d1; asc O ;; 
8: len 8; hex 434f4d504c455445; asc COMPLETE;; 
9: len 4; hex 4f1ae40d; asc O ;; 
10: len 4; hex 4f1ae3d1; asc O ;; 
11: len 0; hex ; asc ;; 

*** (2) TRANSACTION: 
TRANSACTION A42EF1A, ACTIVE 0 sec, process no 30952, OS thread id 1241389376 updating or deleting 
mysql tables in use 1, locked 1 
4 lock struct(s), heap size 1248, 11 row lock(s), undo log entries 1 
MySQL thread id 77901285, query id 705153899 ip-10-190-211-216.ec2.internal 10.190.211.216 root updating 
DELETE FROM items where status = 'DELETED' OR status = 'COMPLETE' LIMIT 2500 
*** (2) HOLDS THE LOCK(S): 
RECORD LOCKS space id 404 page no 1223 n bits 232 index `PRIMARY` of table `queue`.`items` trx id A42EF1A lock_mode X locks rec but not gap 
Record lock, heap no 159 PHYSICAL RECORD: n_fields 12; compact format; info bits 32 
0: len 8; hex 00000000006fe5c4; asc  o ;; 
1: len 6; hex 00000a42ef1a; asc B ;; 
2: len 7; hex 00000000390110; asc  9 ;; 
3: len 1; hex 81; asc ;; 
4: len 11; hex 50524f42455f4556454e54; asc PROBE_EVENT;; 
5: len 15; hex 352f3934302f3934302e70726f6265; asc 5/940/940.probe;; 
6: len 15; hex 50524f42455f4556454e545f393430; asc PROBE_EVENT_940;; 
7: len 4; hex 4f1ae3d1; asc O ;; 
8: len 8; hex 434f4d504c455445; asc COMPLETE;; 
9: len 4; hex 4f1ae40d; asc O ;; 
10: len 4; hex 4f1ae3d1; asc O ;; 
11: len 0; hex ; asc ;; 

*** (2) WAITING FOR THIS LOCK TO BE GRANTED: 
RECORD LOCKS space id 404 page no 11287 n bits 280 index `comm.stat.next.locked` of table `queue`.`items` trx id A42EF1A lock_mode X locks rec but not gap waiting 
Record lock, heap no 181 PHYSICAL RECORD: n_fields 5; compact format; info bits 0 
0: len 11; hex 50524f42455f4556454e54; asc PROBE_EVENT;; 
1: len 8; hex 434f4d504c455445; asc COMPLETE;; 
2: len 4; hex 4f1ae3d1; asc O ;; 
3: len 4; hex 4f1ae40d; asc O ;; 
4: len 8; hex 00000000006fe5c4; asc  o ;; 

*** WE ROLL BACK TRANSACTION (1) 
------------ 
TRANSACTIONS 
------------ 
Trx id counter A42F0C1 
Purge done for trx's n:o < A42EF2E undo n:o < 0 
History list length 117 
LIST OF TRANSACTIONS FOR EACH SESSION: 
---TRANSACTION 0, not started, process no 30952, OS thread id 1241389376 
MySQL thread id 77901343, query id 705156010 ip-10-85-61-62.ec2.internal 10.85.61.62 root 
SHOW ENGINE INNODB STATUS 
---TRANSACTION A2A4783, not started, process no 30952, OS thread id 1100028224 
MySQL thread id 1, query id 705153376 localhost 127.0.0.1 rdsadmin 
+0

他の同様の質問に誰かがコメントした "InnoDBには同時書き込みの問題があります。特にinnodbテーブルの最後にデータを挿入すると問題があります。" – MichaelICE

+1

デッドロックレポートが投稿したSQLと一致しません。それは "アイテム"と呼ばれる別のテーブルのデッドロックを報告しています。 – schtever

+0

より正確なデータを取得できるかどうかを確認します – MichaelICE

答えて

0

深く掘った後、問題がここ

は私がやっていることのいくつかの切り抜きです表面に...別のプログラムで、説明に鍵を使用していない別の選択肢がありました。物事が良く見えます。