MySQL索引和锁

　　索引和锁可以让查询锁定更少的行。如果你的查询从不访问那些不需要访问的行，那么就会锁定更少的行，从两个方面来看这对性能都有好处。首先，虽然innodb的行锁效率很高，内存使用也很少，但是锁定行的时候仍然会带来额外的开销，其次，锁定超过需要的行会增加锁竞争，并减少并发性。

　　innodb只有在访问行的时候才会对其加锁，而索引能够减少innodb访问的行数，从而减少锁的数量。但只有当innodb在存储引擎能够过滤掉不需要的行时才有效。如果索引无法过滤掉无效的行，那么在innodb检索到数据并返回给服务器层以后，MySQL服务器才能应用WHERE子句。这时候，已经无法避免锁定行了：inno代表可以在服务器端过滤掉行后就释放锁，但是在早期的MySQL版本中，innodb只有在事务提交后才能释放锁。

　　通过下面的例子，很好的解释了这些情况

　　SELECT actor_id FROM actor WHERE actor_id < 5 AND actor_id<>1 FOR UPDATE;

　　这些表仅仅会返回2-4之间的行，但是实际上获取了1-4之间行的排他锁，innodb会锁住第一行，这是因为MySQL为该查询选择执行计划是索引范围扫描；换句话说，底层存储引擎操作的是“从索引的开头开始获取满足条件的actor_id<5的记录”服务器并没有告诉innodb可以过滤掉第一行的where条件。注意到explain的Extra列出现了“Using Where ” 这表示MySQL服务器将存储引擎返回行以后再应用where过滤条件。

　　下面的第二个查询就可以证明第一行确实已经被锁定，尽管第一个查询的结果中并没有这个第一行。保持第一个连接打开，然后开启第二个连接并执行如下语句：

　　SELECT actor_id FROM actor WHERE actor_id = 1 FOR UPDATE.

　　这个查询就会被挂起，直到第一个事务释放第一行的锁。这个行为对于基于语句的复制的正常运行来说是必要的。

　　就像这个例子显示的，即使使用了索引，innodb可能也会锁住一些不需要的数据。如果不能使用索引查找和锁定行的话问题可能会很糟糕，MySQL会做全表扫描并锁定所有的行，而不管是不是需要。

　　关于innodb，索引和锁有一些很少有人知道的细节：innodb在二级索引上使用共享锁（读锁），但访问主键索引需要排他锁（写），这消除了使用覆盖索引的可能性，并且使得SELECT FOR UPDATE 比LOCK IN SHARE MODE  或非锁定查询要慢得多。