锁是需要事务结束后才释放的。
公司主营业务：做网站、成都网站建设、移动网站开发等业务。帮助企业客户真正实现互联网宣传，提高企业的竞争能力。创新互联建站是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化，感谢他们对我们的高要求，感谢他们从不同领域给我们带来的挑战，让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。创新互联建站推出华龙免费做网站回馈大家。
一个是 MVCC，一个是两阶段锁协议。
为什么要并发控制呢？是因为多个用户同时操作 MySQL 的时候，为了提高并发性能并且要求如同多个用户的请求过来之后如同串行执行的一样（为了解决脏读、不可重复读、幻读）
官方定义：
两阶段锁协议是指所有事务必须分两个阶段对数据加锁和解锁，在对任何数据进行读、写操作之前，事务首先要获得对该数据的封锁；在释放一个封锁之后，事务不再申请和获得任何其他封锁。
对应到 MySQL 上分为两个阶段：
但是两阶段锁协议不要求事务必须一次将所有需要使用的数据加锁（innodb在需要的索引列数据才锁行），并且在加锁阶段没有顺序要求，所以这种并发控制方式会形成死锁。
MySQL有两种死锁处理方式：
死锁检测 （默认开启）
死锁检测的原理是构建一个以事务为顶点、锁为边的有向图，判断有向图是否存在环，存在即有死锁。
回滚
检测到死锁之后，选择插入更新或者删除的行数最少的事务回滚，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段来判断。
收集死锁信息：
减少死锁：
死锁解决：
可直接在mysql命令行执行：show engine innodb status\G; 查看造成死锁的sql语句，分析索引情况，然后优化sql然后show processlist;另外可以打开慢查询日志，linux下打开需在my.cnf的[mysqld]里面加上以下内容：
本文死锁场景皆为工作中遇到（或同事遇到）并解决的死锁场景，写这篇文章的目的是整理和分享，欢迎指正和补充，本文死锁场景包括：
注 ：以下场景隔离级别均为默认的Repeatable Read；
前提 ：表 t_user 的 uid 字段创建了唯一索引，并拥有可更新字段age。
场景复现 ：
相应业务案例和解决方案 ：
该场景常见于事务中存在for循环更新某条记录的情况，死锁日志显示 lock_mode X locks rec but not gap waiting （即行锁而非间隙锁），解决方案：
表结构 :
场景复现 ：
首先查询表中目前存在的记录：
执行两个事务的操作：
死锁原因分析 ：
解决方案 ：
t_user结构改造为：
场景复现操作（几率不高） ：
假设存在以下数据 ：
死锁分析 ：
事务1 ：
① 锁住zone_id=1对应的间隙锁: zoneId in (1,2)
② 锁住索引zone_id=1对应的主键索引行锁id = [1,2]
③ 锁住uid=1对应的间隙锁: uid in (1, 2)
④ 锁住uid=1对应的主键索引行锁: id = [1, 3]
事务2 ：
① 锁住zone_id=2对应的间隙锁: zoneId in (1,2)
② 锁住索引zone_id=2对应的主键索引行锁id = [3,4]
③ 锁住uid=2对应的间隙锁: uid in (1, 2)
④ 锁住uid=2对应的主键索引行锁: id = [2, 4]
解决方案 ：创建联合索引，使执行计划只会用到一个索引。
测试表结构 :
场景复现操作 ：
解决办法：尽量避免这种插入又回滚的场景。
避免死锁的原则：
目测不是因为存储过程内sql导致的死锁:
因为存储过程内只有一条insert语句会持有锁，也只持有一把锁。所以不会导致死锁。
引起死锁肯定是由于资源共享冲突，事务是保证一个操作单元能执行顺利或失败，保证数据的完整性的。
对于资源冲突肯定是需要锁来控制，也就是使用数据的隔离机制和同步锁来控制的，数据库的隔离机制修改影响会比较大，所以建议在dao层使用同步或者加锁来防止deadlock
但是可能会影响部分性能
一、show ENGINE INNODB status
查看死锁位置，分析。
二、
首先解决死锁可以从死锁发生的条件入手，最容易解决的就是更改获取资源的顺序；
其次是避免长事务，让事务执行的时间尽可能少，让事务的覆盖范围尽可能小，长事务会导致并发度降低，且会有更多的SQL查 询延迟；
给整个方法加事务是否是必须的？可以不加事务的尽量不加。