mysql 并发控制

1、多个线程同时修改数据，存在数据不一致的情况，也就是并发控制的问题。
2、mysql提供读锁和写锁，读锁之上可以再加读锁，不能加写锁，而写锁之上不能加任何锁。也就是说，读锁是共享的，写锁是排他的。
3、锁粒度，为了更好的并发控制，锁的粒度应该尽可能小，也就是只锁定修改的数据。但是，锁本身也有一定的开销，包括获取锁，检查锁是否释放，释放锁，这些操作也耗费一定的资源。锁的粒度小，在并发控制的时候，也就意味着需要更多的锁，锁的总开销也就越大。
4、根据锁的粒度，分为表锁和行锁，mysql本身使用表锁来实现不同的目的，比如alter table，这个时候会忽略存储引擎的锁机制。存储引擎支持表锁和行锁，不同存储引擎的实现不同。
5、特别注意：mysql支持不同的事务隔离级别，隔离级别越高，锁的粒度越大，也就是锁的内容越多。比如：
考虑下面的情况，A，B客户端的事务隔离级别都是read-uncommitted, 锁的粒度是行锁。
步骤一、A执行start transaction，修改一条记录
步骤二、B执行start transaction，修改另一条记录
二者是不阻塞的，证明read-uncommitted 是行锁。同理，可以证明read-committed是行锁，repeatable-read和serializable是表锁。

注意：加什么锁，锁多大范围，和很多因素有关，包括是否有索引，执行的操作等。比如上面的情况，A、B都是repeatable-read，A进行select，B进行update不阻塞。但是A进行update，B进行update就会阻塞。

6、死锁，mysql在事务中，InnoDB会根据事务隔离级别自动锁定，而释放实在事务commit或者rollback的时候才释放。这就会存在死锁的情况，考虑下面的情况：
A，B客户端的事务隔离级别都是read-uncommitted, 锁的粒度是行锁。
步骤一、A执行start transaction，修改记录1
步骤二、B执行start transaction，修改记录2
步骤三、A修改记录2
步骤四、B修改记录1
出现死锁，不过mysql功能很强大，可以检测出这种死锁，B修改记录1的时候报错 ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting trans
action