锁的认识
1.1 锁的解释
计算机协调多个进程或线程并发访问某一资源的机制
1.2 锁的重要性
在数据库中，除传统计算资源（CPU、RAM、I\O等）的争抢，数据也是一种供多用户共享的资源。 如何保证数据并发访问的一致性，有效性，是全部数据库必需要解决的问题。 锁冲突也是影响数据库并发访问性能的一个重要因素，所以锁对数据库尤为重要。
1.3 锁的缺点
加锁是消耗资源的，锁的各类操做，包括得到锁、检测锁是否已解除、释放锁等 ，都会增长系统的开销。
锁的类型
2.1 表锁
种类
读锁（read lock），也叫共享锁（shared lock）
针对同一份数据，多个读操做能够同时进行而不会互相影响（select）
写锁（write lock），也叫排他锁（exclusive lock）
当前操做没完成以前，会阻塞其它读和写操做（update、insert、delete）
存储引擎默认锁 ： MyISAM
特色
1. 对整张表加锁 2. 开销小 3. 加锁快 4. 无死锁 5. 锁粒度大，发生锁冲突几率大，并发性低
结论
1. 读锁会阻塞写操做，不会阻塞读操做 2. 写锁会阻塞读和写操做
MyISAM的读写锁调度是写优先，这也是MyISAM不适合作写为主表的引擎，由于写锁之后，其它线程不能作任何操做，大量的更新使查询很可贵到锁，从而形成永远阻塞。
2.2 行锁
种类
读锁（read lock），也叫共享锁（shared lock）
容许一个事务去读一行，阻止其余事务得到相同数据集的排他锁
若事务T对数据对象A加上S锁，则事务T能够读A但不能修改A，其余事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。这保证了其余事务能够读A，但在T释放A上的S锁以前不能对A作任何修改。
写锁（write lock），也叫排他锁（exclusive lock）
容许得到排他锁的事务更新数据，阻止其余事务取得相同数据集的共享锁和排他锁
若事务T对数据对象A加上X锁，事务T能够读A也能够修改A，其余事务不能再对A加任何锁，直到T释放A上的锁。
排他锁指的是一个事务在一行数据加上排他锁后，其余事务不能再在其上加其余的锁。mysql InnoDB引擎默认的修改数据语句
：update,delete,insert都会自动给涉及到的数据加上排他锁，select语句默认不会加任何锁类型，若是加排他锁能够使用select …for update语句，加共享锁能够使用select … lock in share mode语句。
因此加过排他锁的数据行在其余事务种是不能修改数据的，也不能经过for update和lock in share mode锁的方式查询数据，但能够直接经过select …from…查询数据，由于普通查询没有任何锁机制。
意向共享锁（IS） 一个事务给一个数据行加共享锁时，必须先得到表的IS锁
意向排它锁（IX） 一个事务给一个数据行加排他锁时，必须先得到该表的IX锁
存储引擎默认锁 ：InnoDB
特色
1. 对一行数据加锁 2. 开销大 3. 加锁慢 4. 会出现死锁 5. 锁粒度小，发生锁冲突几率最低，并发性高
事务并发带来的问题
1. 更新丢失 解决：让事务变成串行操做，而不是并发的操做，即对每一个事务开始---对读取记录加排他锁 2. 脏读 解决：隔离级别为Read uncommitted 3. 不可重读 解决：使用Next-Key Lock算法来避免 4. 幻读 解决：间隙锁（Gap Lock）
如何上锁？
3.1 表锁
隐式上锁（默认，自动加锁自动释放）
select //上读锁
insert、update、delete //上写锁
显式上锁（手动）
lock table tableName read;//读锁 lock table tableName write;//写锁
解锁（手动）
unlock tables;//全部锁表
3.2 行锁
隐式上锁（默认，自动加锁自动释放）
select //不会上锁
insert、update、delete //上写锁
显式上锁（手动）
select * from tableName lock in share mode;//读锁 select * from tableName for update;//写锁
解锁（手动）
1. 提交事务（commit） 2. 回滚事务（rollback） 3. kill 阻塞进程
优化建议
1. 尽量让全部数据检索都经过索引来完成，避免无索引行锁升级为表锁 2. 合理设计索引，尽可能缩小锁的范围 3. 尽量较少检索条件，避免间隙锁 4. 尽可能控制事务大小，减小锁定资源量和时间长度 5. 尽量低级别事务隔离
死锁
6.1 解释
指两个或者多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而致使恶性循环的现象
6.2 产生的条件
1. 互斥条件：一个资源每次只能被一个进程使用 2. 请求与保持条件：一个进程因请求资源而阻塞时，对已得到的资源保持不放 3. 不剥夺条件：进程已得到的资源，在没有使用完以前，不能强行剥夺 4. 循环等待条件：多个进程之间造成的一种互相循环等待的资源的关系
6.1 解决
1. 查看死锁：show engine innodb status \G 2. 自动检测机制，超时自动回滚代价较小的事务（innodb_lock_wait_timeout 默认50s） 3. 人为解决，kill阻塞进程（show processlist） 4. wait for graph 等待图（主动检测）
6.1 如何避免
1. 加锁顺序一致，尽量一次性锁定所需的数据行 2. 尽可能基于primary（主键）或unique key更新数据 3. 单次操做数据量不宜过多，涉及表尽可能少 4. 减小表上索引，减小锁定资源 5. 尽可能使用较低的隔离级别 6. 尽可能使用相同条件访问数据，这样能够避免间隙锁对并发的插入影响 7. 精心设计索引，尽可能使用索引访问数据 8. 借助相关工具：pt-deadlock-logger