Bug #55859 | MySQL and InnoDB locks are taken in different orders in different statements | ||
---|---|---|---|
Submitted: | 9 Aug 2010 20:21 | Modified: | 27 Dec 2010 11:11 |
Reporter: | Ben Krug | Email Updates: | |
Status: | Verified | Impact on me: | |
Category: | MySQL Server: InnoDB storage engine | Severity: | S4 (Feature request) |
Version: | 5.1 | OS: | Any |
Assigned to: | CPU Architecture: | Any |
[9 Aug 2010 20:21]
Ben Krug
[9 Aug 2010 20:53]
Nagavamsi Ponnekanti
In multi-statement xacts there could be innodb locks held from previous statements. As a result, enforcing the order "innodb locks before mysql locks" is better than enforcing the order "mysql locks before innodb locks". So it would be good if the proposed configurable option enforces the order "innodb locks before mysql locks". (That probably means the config option would affect DML statements rather than "lock tables" statement.)
[10 Aug 2010 12:49]
Konstantin Osipov
Fixed in 5.5 with the new MDL.
[10 Aug 2010 12:50]
Konstantin Osipov
The suggested cure is worse than the disease.
[10 Aug 2010 12:55]
Konstantin Osipov
What *can* be further improved in 5.5, is that, since we no longer needs the so called "MySQL locks" (i.e. thr_lock table level locks) when working with InnoDB engine, we could never try to acquire them for InnoDB tables. But this will only lead to fewer mutex acquisitions, and otherwise will have no effect.