What is the difference between InnoDB locks and transaction isolation level? We’ll discuss it in this post.
Recently I received a question from a user about one of my earlier blog posts. Since it wasn’t sent as a comment, I will answer it here. The question:
> I am reading your article:
> Full table scan locks whole table.
> Some bad select (read) query can do full table scan on InnoDB, does it lock whole table please?
> My understanding was that SELECT (read) blocks another DML only in MyISAM.
To answer this question, we to need understand two different concepts: locking and transaction isolation level.
In the default transaction isolation mode for InnoDB, REPEATABLE READ and the lower SELECT levels don’t block any DML unless it uses SELECT … FOR UPDATE or SELECT … LOCK IN SHARE MODE . On slide 20 (31) ofmy presentation, I use the SELECT … FOR UPDATE statement (this is why a lock is seen).
However, if transaction isolation mode is SERIALIZABLE , then SELECT can block updates. You can see this in the example below:
mysql1> set transaction isolation level serializable; Query OK, 0 rows affected (0,00 sec) mysql1> begin; Query OK, 0 rows affected (0,00 sec) mysql1> select * from employees join titles using(emp_no); c936e6fc4c6cbaf77679ba5013339dff - 443308 rows in set (29,69 sec) mysql2> begin; Query OK, 0 rows affected (0,00 sec) mysql2> update titles set title='Engineer' where emp_no=15504; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
Regarding the different level locks set by InnoDB, I recommend that you follow the links on slide 37 (67) ofthe presentation, especially “InnoDB Locking Explained With Stick Figures” by Bill Karwin. Innodb table locks are also explained very well inthis blog post by Peter Zaitsev.