mysql 开发进阶篇系列 13 锁问题(关于表锁，死锁示例，锁等待设置)

一. 什么时候使用表锁

　　对于INNODB表，在绝大部分情况下都应该使用行锁。在个别特殊事务中，可以考虑使用表锁（建议）。
　　1. 事务需要更新大部份或全部数据，表又比较大，默认的行锁不仅使这个事务执行效率低，可能造成其他事务长时间锁等待和锁冲突，这种情况考虑使用表锁来提高事务的执行速度(具我在sql server中的经历，该大表有上100w，删除40w，表锁有时会造成长时间未执行完成. 还是使用分批来执行好)。
　　2. 事务涉及多个表，比较复杂，很可能引起死锁，造成大量事务回滚。这种情况可以考虑一次性锁定事务涉及的表，避免死锁，减少数据库因事务回滚带来的开销。
　　使用表锁注意两点
　　　　(1) lock tables虽然可以给innodb加表锁，但表锁不是由innodb存储引擎层管理，则是由上层mysql server负责。仅当autocommit=0, innodb_table_locks=1(默认设置)时,innodb层才知道mysql加的表锁,mysql server也才能感知innodb加的行锁。
　　　　(2) 用lock tables对innodb表加锁时要注意, 要将autocommit 设置为0,否则mysql 不会给表加锁； 事务结束前，不要用unlock tables释放表锁，因为它会隐式的提交事务。 commit 或rollback 并不能释放用lock tables 加的表锁。必须用unlock tables释放表锁。

　　　　下面在5.7版本数据库中，会话2也会阻塞,按上面说法是不会阻塞的，因为会话1没有设置SET autocommit =0(以后在论证)

-- 会话1 给city加表锁读,  不设置  SET autocommit =0
  LOCK TABLES city READ

  --  会话2 会阻塞
 UPDATE city SET CityCode='005' WHERE city_id=103  

  -- 会话1提交
 COMMIT;
 -- 会话1 释放表锁
 UNLOCK TABLES;

二. 关于死锁

　　在myisam中是使用的表锁，在获得所需的全部锁时， 要么全部满足，要么等待，因此不会出现死锁。下面在innodb中演示一个死锁例子：

会话1	会话2
SET autocommit =0 SELECT * FROM city  WHERE city_id=103 FOR UPDATE;	SET autocommit =0 SELECT * FROM cityNew  WHERE city_id=103 FOR UPDATE;
-- 因为会话2 已获得排他锁， 该语句等待  SELECT * FROM cityNew  WHERE city_id=103 FOR UPDATE;
	-- 死锁  SELECT * FROM city  WHERE city_id=103 FOR UPDATE; 错误代码： 1213 Deadlock found when trying to get lock; try restarting transaction

　　上面案例中， 两个事务都需要获得对方持有的排他锁才能继续完成事务，这种循环锁等待就是典型的死锁。 发生死锁后，innodb会自动检测到，并使一个事务释放锁并回退(回滚)，另一个事务得锁完成事务。

三. 锁等待查看　　　　

　　涉及外部锁或表锁，innodb并不能完全自动检测到死锁，这需要设置锁等待超时参数innodb_lock_wait_timeout来解决(设置需慎重)，这个参数并不是只用来解决死锁问题，在并发下，大量事务无法立即获得所需锁而挂起，将占用大量资源，甚至拖跨数据库 (在sql server中默认是-1 总是等待)。

--  下面是5秒  获取不到锁就超时
SHOW GLOBAL VARIABLES LIKE 'innodb_lock_wait_timeout';