您的位置:首页 > 数据库 > MySQL

mysql 并发控制

2015-05-31 15:54 826 查看
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
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: