Details
-
New Feature
-
Status: Open (View Workflow)
-
Minor
-
Resolution: Unresolved
-
None
Description
Row level locking and concurrency is becoming a much bigger issue than it used to be, in particular with applications that are migrated from some other system with different locking semantics. There are ways of tracking row level locks, there are the INNODB_LOCK_WAITS I_S tables and in the performance schema. But this assumes that you are there to track when a there is a lock and run the appropriate SQL command. In practice this has proved to be difficult, in particular when the applications are large and complex. In addition, these locks might cause issues only when the full application is run so row locks and timeout are all over the place and makes the sequence of events really difficult to track.
My suggested fix for this is to amend the slow query log with the ability to show the lock tree for a statement that gets into the slow query log, in the case when this statement is waiting for a lock that is. This would be optional and not enabled by default, as row locks are usually acceptable if they don't lock for too long and this might create some unnecessary "clutter" in the slow query log and might also increase the size of this unnecessarily. My suggestion is to add this as a new value to the log_slow_verbosity system variable.