撰写锁的认识
一.首先要知道什么是锁
锁是计算机协调多个进程或线程并发访问某一资源的机制。
二.锁能解决什么问题
因为数据也是一种供多用户共享的资源，所以锁可以保证数据并发访问的一致性，有效性
三.锁会带来的问题
加锁是消耗资源的，锁的各种操作，包括获得锁、检测锁是否已解除、释放锁等 ，都会增加系统的开销。
锁的类型
一.表锁( 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
乐观锁与悲观锁
悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作
实现机制：表锁、行锁等
实现层面：数据库本身
适用场景：并发量大
乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性
实现机制：提交更新时检查版本号或者时间戳是否符合
实现层面：业务代码
适用场景：并发量小