Sometimes, yes, but row locks are held until the transaction commits, so of course even short-running statements can block things. In most of the cases I’ve needed to track down, it’s usually something like “update table1 join client… set table1.clientname=client.nickname” and then the client table’s rows are locked until the transaction commits. Take a poorly-behaved program that doesn’t commit for a while, add 99 other things running at the same time, and it’s basically impossible to figure out who really has the lock you need to kill and un-freeze the works.

I’ve been spending some time in the InnoDB source trying to figure out if there’s a way to just see which transaction holds the lock, but I don’t know the code that well. (The locking code is pretty complicated). That would be my preferred solution.

Other then the cool show status variable that allows for easy graphing, what other information does this show? I’d like to get information as to why the table lock is established, and why it’s taking so long.

Some suggestions that may answer these questions:

What about showing the number of rows the lock needs to hold as an indicator to why the lock is across the entire table?

A page to row conversion, to see which processes are trying to operate on the same page/row, which could be an indicator as to why a lock across the table is needed.

This is some great work with a bunch of expandable information.

Thanks, and a merry Christmas to you as well!