> Innodb is not row-level locking -- it's memory-page-level-locking. A > memory page is usually small, so it's almost like row-level locking, > but not quite. Perhaps you're running up against that? > > What does the query log say which queries were running? How do you > know it's the delete that's taking the lock, and not an update (the > error message said an update or a delete)?
Please see InnoDB status on this URL http://forums.mysql.com/read.php?22,68977,68977#msg-68977 You'll see --TRANSACTION 0 476648265, ACTIVE 530 sec, process no 13965, OS thread id 3152999360 updating or deleting, thread declared inside InnoDB 293 mysql tables in use 1, locked 1 ----> Locked 1 :) 11090 lock struct(s), heap size 634176, undo log entries 930711 MySQL thread id 16831, query id 11504020 localhost 127.0.0.1 root updating delete from t_outgoing_sms_3t where month(out_sms_time)=1 > > -Sheeri > > On 2/10/06, Ady Wicaksono <[EMAIL PROTECTED]> wrote: >> So where's the row locking? >> >> I configure my database with Innodb + READ COMMITED, by this >> configuration >> by using autocommit=1, delete should be done on data commited to disk. >> Other thread should be able to insert/update. >> >> CMIIW >> >> >> > Tables are locked on delete because, like an update, they are changing >> > data. >> > >> > Imagine issuing a REPLACE statement after a DELETE statement. If the >> > DELETE locks the table, then the REPLACE happens AFTER the DELETE, as >> > you wanted. If the DELETE does not lock the table, then it's possible >> > the REPLACE will happen before the DELETE, and the DELETE will delete >> > the row you just replaced. >> > >> > -Sheeri >> > >> > On 2/9/06, Ady Wicaksono <[EMAIL PROTECTED]> wrote: >> >> Why table locked on delete? >> >> >> > >> > >> >> > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
