锁的认识
一.首先要知道什么是锁
锁是计算机协调多个进程或线程并发访问某一资源的机制。
二.锁能解决什么问题
因为数据也是一种供多用户共享的资源,所以锁可以保证数据并发访问的一致性,有效性
三.锁会带来的问题
加锁是消耗资源的,锁的各种操作,包括获得锁、检测锁是否已解除、释放锁等 ,都会增加系统的开销。
锁的类型
一.表锁( MyISAM 默认下就是表锁)
1)特点:
1. 对整张表加锁
2. 开销小
3. 加锁快
4. 无死锁
5. 锁粒度大,发生锁冲突概率大,并发性低
2)种类:
1.读锁(select 的时候自动触发)
也叫共享锁(shared lock) 针对同一份数据,多个读操作可以同时进行而不会互相影响
(但是在上了读锁的时候,便不能做写操作,只有解锁的时候,才可以做写操作)
2.写锁(update、insert、delete 的时候自动触发)
也叫排他锁(exclusive lock) 当前操作没完成之前,会阻塞其它(线程)的读和写操作
3)上锁方式:
1.隐式上锁(默认,自动加锁自动释放)
select //上读锁 insert、update、delete //上写锁
2.显式上锁(手动)
lock table tableName read;//读锁 lock table tableName write;//写锁
3.解锁(手动)
unlock tables;//所有锁表
4)排查锁:
查看表锁情况 show open tables; 表锁分析 show status like 'table%';
5)结论:
1. 读锁会阻塞写操作,不会阻塞读操作
2. 写锁会阻塞读和写操作
二.行锁( InnoDB 默认下就是行锁)
这里要注意的是,只有通过索引条件检索数据时,InnoDB 才会使用行级锁,否则会使用表级锁(索引失效,行锁变表锁)
1)特点:
1. 对一行数据加锁
2. 开销大
3. 加锁慢
4. 会出现死锁
5. 锁粒度小,发生锁冲突概率最低,并发性高
2)种类:
1.读锁(对比表锁,select 不会自动上锁)
也叫共享锁(shared lock),允许一个事务去读一行,阻止其他事务获得相同数据集的排他锁
2.写锁(insert、update、delete 的时候自动触发)
也叫排他锁(exclusive lock),允许获得排他锁的事务更新数据,阻止其他事务取得相同数据集的共享锁和排他锁
(不过即使上了写锁,其他事务也可以读操作,因为 InnoDB 有 MVCC 机制(多版本并发控制),可以使用快照读,而不会被阻塞)
3.意向共享锁(IS)
一个事务给一个数据行加共享锁时,必须先获得表的IS锁
4.意向排它锁(IX)
一个事务给一个数据行加排他锁时,必须先获得该表的IX锁
3)上锁方式:
隐式上锁(默认,自动加锁自动释放)
select //不会上锁 insert、update、delete //上写锁
显式上锁(手动)
select * from tableName lock in share mode;//读锁 select * from tableName for update;//写锁
解锁(手动)
1. 提交事务(commit) 2. 回滚事务(rollback) 3. kill 阻塞进程
4)会带来的一些问题:
1. 更新丢失
解决:让事务变成串行操作,而不是并发的操作,即对每个事务开始—对读取记录加排他锁
2. 脏读
解决:隔离级别为Read uncommitted
3. 不可重读
解决:使用Next-Key Lock算法来避免
4. 幻读
解决:间隙锁(Gap Lock)
5)行锁分析
show status like 'innodb_row_lock%'; innodb_row_lock_current_waits //当前正在等待锁定的数量 innodb_row_lock_time //从系统启动到现在锁定总时间长度 innodb_row_lock_time_avg //每次等待所花平均时间 innodb_row_lock_time_max //从系统启动到现在等待最长的一次所花时间 innodb_row_lock_waits //系统启动后到现在总共等待的次数
6)优化建议
1. 尽可能让所有数据检索都通过索引来完成,避免无索引行锁升级为表锁
2. 合理设计索引,尽量缩小锁的范围
3. 尽可能较少检索条件,避免间隙锁
4. 尽量控制事务大小,减少锁定资源量和时间长度
5. 尽可能低级别事务隔离
死锁
1.定义
指两个或者多个事务在同一资源上相互占用,并请求锁定对方占用的资源,从而导致恶性循环的现象
2.产生的条件
1. 互斥条件:一个资源每次只能被一个进程使用
2. 请求与保持条件:一个进程因请求资源而阻塞时,对已获得的资源保持不放
3. 不剥夺条件:进程已获得的资源,在没有使用完之前,不能强行剥夺
4. 循环等待条件:多个进程之间形成的一种互相循环等待的资源的关系
3.解决
1. 查看死锁:show engine innodb status \G
2. 自动检测机制,超时自动回滚代价较小的事务(innodb_lock_wait_timeout 默认50s)
3. 人为解决,kill阻塞进程(show processlist)
4. wait for graph 等待图(主动检测)
4.如何避免
1. 加锁顺序一致,尽可能一次性锁定所需的数据行
2. 尽量基于primary(主键)或unique key更新数据
3. 单次操作数据量不宜过多,涉及表尽量少
4. 减少表上索引,减少锁定资源
5. 尽量使用较低的隔离级别
6. 尽量使用相同条件访问数据,这样可以避免间隙锁对并发的插入影响
7. 精心设计索引,尽量使用索引访问数据
8. 借助相关工具:pt-deadlock-logger
乐观锁与悲观锁
悲观锁:假定会发生并发冲突,屏蔽一切可能违反数据完整性的操作
实现机制:表锁、行锁等
实现层面:数据库本身
适用场景:并发量大
乐观锁:假设不会发生并发冲突,只在提交操作时检查是否违反数据完整性
实现机制:提交更新时检查版本号或者时间戳是否符合
实现层面:业务代码
适用场景:并发量小