mysql deadlocks (innodb)!!!

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
Antworten
Benutzeravatar
MasterLR
Beiträge: 160
Registriert: 16.12.2003 21:15:03
Wohnort: NRW

mysql deadlocks (innodb)!!!

Beitrag von MasterLR » 07.08.2005 18:27:17

ich weis -> das thema ist eigentlich nicht passend im debian forum. allerdings habe ich tagelang nach einer lösung gesucht und nicht mal ansatzweise etwas gefunden.

nun wollt ich es in mein lieblingsforum versuchen *einschleim* - auch wenn es nicht direkt hierher gehört:

also, ich habe eine innodb tabelle mit folgenden schema:

Code: Alles auswählen

CREATE TABLE `message` (
  `ID` int(11) unsigned NOT NULL auto_increment,
  `COMP_ID` int(11) unsigned NOT NULL default '0',
  `SENDER` varchar(30) default NULL,
  `RECEIVER` varchar(30) default NULL,
  `MSGTIME` datetime NOT NULL default '0000-00-00 00:00:00',
  `MESSAGE` text NOT NULL,
  `READFLAG` int(11) unsigned default '0',
  `READTIME` datetime default '0000-00-00 00:00:00',
  `READER_ID` varchar(20) default NULL,
  `OUTMSG` int(11) unsigned NOT NULL default '0',
  `LASTCHANGE` datetime default NULL,
  `LASTUSER_ID` varchar(20) default NULL,
  PRIMARY KEY  (`ID`),
  KEY `id1` (`COMP_ID`,`READFLAG`,`MSGTIME`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
in dieser tabelle (und vorallem _nur_ in dieser tabelle) bekomme ich ständig deadlocks ohne das ich mir erklären kann wieso!?

folgendes ist die ausgabe bei "show engine innodb status":

Code: Alles auswählen

------------------------
LATEST DETECTED DEADLOCK
------------------------
050804 12:52:22
*** (1) TRANSACTION:
TRANSACTION 0 610886, ACTIVE 0 sec, process no 2373, OS thread id 1251220400 fetching rows
mysql tables in use 1, locked 1
LOCK WAIT 73 lock struct(s), heap size 5504
MySQL thread id 116, query id 548022 localhost root Searching rows for update
UPDATE message SET READFLAG = 0, READTIME='2005-08-05 09:52:06' WHERE COMP_ID=40217101 AND RECEIVER='154' AND OUTMSG=1 AND MSGTIME <= '2005-08-05 09:52:06' AND READFLAG = 1
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 1794 n bits 168 index `PRIMARY` of table `test/message` trx id 0 610886 lock_mode X locks rec but not gap waiting
Record lock, heap no 44 PHYSICAL RECORD: n_fields 14; 1-byte offs TRUE; info bits 0
 0: len 4; hex 0000430f; asc   C ;; 1: len 6; hex 00000006c0da; asc       ;; 2: len 7; hex 800000002d0084; asc     -  ;; 3: len 4; hex 0265aa0e; asc  e  ;; 4: len 3; hex 414245; asc ABE;; 5: len 4; hex 4e554c4c; asc NULL;; 6: len 8; hex 8000000000000000; asc         ;; 7: len 24; hex 46554e4b54494f4e49455254204441532053595354454d3f; asc FUNKTIONIERT DAS SYSTEM?;; 8: len 4; hex 00000001; asc     ;; 9: len 8; hex 8000000000000000; asc         ;; 10: len 2; hex 3130; asc 10;; 11: len 4; hex 00000000; asc     ;; 12: len 8; hex 8000000000000000; asc         ;; 13: len 4; hex 4e554c4c; asc NULL;;

*** (2) TRANSACTION:
TRANSACTION 0 610882, ACTIVE 0 sec, process no 2373, OS thread id 1251089328 fetching rows, thread declared inside InnoDB 302
mysql tables in use 1, locked 1
60 lock struct(s), heap size 5504
MySQL thread id 117, query id 548020 localhost root Updating
UPDATE message SET READFLAG = 1, READTIME='2005-08-05 09:52:10' WHERE COMP_ID=50204104 AND RECEIVER='12422' AND OUTMSG=1 AND MSGTIME <= '2005-08-05 09:52:10' AND READFLAG = 0
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 0 page no 1794 n bits 168 index `PRIMARY` of table `test/message` trx id 0 610882 lock_mode X
Record lock, heap no 44 PHYSICAL RECORD: n_fields 14; 1-byte offs TRUE; info bits 0
 0: len 4; hex 0000430f; asc   C ;; 1: len 6; hex 00000006c0da; asc       ;; 2: len 7; hex 800000002d0084; asc     -  ;; 3: len 4; hex 0265aa0e; asc  e  ;; 4: len 3; hex 414245; asc ABE;; 5: len 4; hex 4e554c4c; asc NULL;; 6: len 8; hex 8000000000000000; asc         ;; 7: len 24; hex 46554e4b54494f4e49455254204441532053595354454d3f; asc FUNKTIONIERT DAS SYSTEM?;; 8: len 4; hex 00000001; asc     ;; 9: len 8; hex 8000000000000000; asc         ;; 10: len 2; hex 3130; asc 10;; 11: len 4; hex 00000000; asc     ;; 12: len 8; hex 8000000000000000; asc         ;; 13: len 4; hex 4e554c4c; asc NULL;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 1823 n bits 176 index `PRIMARY` of table `test/message` trx id 0 610882 lock_mode X waiting
Record lock, heap no 41 PHYSICAL RECORD: n_fields 14; 1-byte offs FALSE; info bits 0
 0: len 4; hex 00004eb3; asc   N ;; 1: len 6; hex 00000006da5c; asc      \;; 2: len 7; hex 800000002d0084; asc     -  ;; 3: len 4; hex 0265aa0d; asc  e  ;; 4: len 3; hex 333331; asc 331;; 5: len 2; hex 3736; asc 76;; 6: len 8; hex 8000000000000000; asc         ;; 7: len 30; hex 486920526f626572742e2e2e2e2e2e2e2e2e2e2e2e2e2e2e0d0a68696572; asc Hi Robert...............  hier;...(truncated); 8: len 4; hex 00000001; asc     ;; 9: len 8; hex 8000000000000000; asc         ;; 10: len 4; hex 4e554c4c; asc NULL;; 11: len 4; hex 00000001; asc     ;; 12: len 8; hex 8000000000000000; asc         ;; 13: len 3; hex 333331; asc 331;;

*** WE ROLL BACK TRANSACTION (2)
beide befehle updaten eigentlich komplett andere datensätze (siehe where bedingung). nun verstehe ich nicht wieso es zu diesen lock bzw. dann zu den deadlock kommt???

wenn mir da einer nur einen ansatz liefern kann oder ein tipp hat wo ich weiterführende infos zu innodb deadlocks bekomme (mysql.com dokus habe ich alle durchgewälzt, groups.google.de auch schon gesucht -> es gibt kaum ausführliche infos über deadlocks bzw. finde ich nichts) wäre ich sehr dankbar...

Antworten