文章目录
概念
计算机协调多个进程或线程并发访问某一资源的机制
防止多事务并发造成数据不统一，避免脏写、脏读、不可重复读、幻读等问题
脏写：事务A和事物B同时改一行数据，最后的更新覆盖了其他事务所做的更新
脏读：事务A读取到了事务B已经修改但尚未提交的数据
不可重复读：事务A内部的相同查询语句在不同时刻读出的结果不一致，不符合隔离性
幻读：事务A读取到了事务B提交的新增数据，不符合隔离性
隔离级别
// 查看当前数据库的事务隔离级别
show variables like 'tx_isolation';
// 设置事务隔离级别
set tx_isolation = 'REPEATABLE-READ';
Mysql默认隔离级别为可重复读
未提交读（READ UNCOMMITTED）
事务B可以读到事务A未提交的数据
提交读（READ COMMITTED）
事务B可以读到事务A提交的数据
可重复读（REPEATABLE READ）
事务B连接之后，读到的一直是连接开始的数据
可重复读的隔离级别下使用了MVCC(multi-version concurrency control)机制，select操作不会更新版本号，是快照读（历史版本）；insert、update和delete会更新版本号，是当前读（当前版本）。
可串行化（SERIALIZABLE）
事务A操作未提交，事务B查询将一直处于等待状态
并发性很低，开发中很少会用到
锁分类
按性能
乐观锁（用版本对比来实现）
悲观锁
按照锁定机制
全局锁
作用范围：库(database)
实现层：SQL layer层
影响：整个库处于只读状态，所有更新操作都将阻塞
使用场景：全库逻辑备份（会影响业务运行，正常业务数据无法写入，无法同步，不推荐）
// 加锁
flush tables with read lock;
// 释放锁，或者断开事务连接，自动释放全局锁
unlock tables;
表锁
作用范围：表
实现层：SQL layer层
优点：开销小、加锁快，不会出现死锁
缺点：锁定粒度大，发生锁冲突的概率最高，并发度最低
场景：一般用在整表数据迁移
读S/写X锁——悲观锁
查看表锁状态变量
show status like 'table%';
- table_locks_immediate：产生表级锁定的次数；
- table_locks_waited：出现表级锁定争用而发生等待的次数
表锁两种表现形式：表共享读锁（Table Read Lock）、表独占写锁（Table Write Lock）
// 手动增加表锁
lock table tblname read(write);
// 查看表锁情况
show open tables;
// 删除表锁
unlock tables;
读锁影响：
1、自身和其他事务都能读
2、自身无法读取其他表，其他事务可以
3、自身写入或更新表会报错，其他事务将处于等待状态
写锁影响：
自身查询和写入都没问题，其他事务处于等待状态
元数据锁(meta data lock, MDL)
不需要显示使用，访问一个表的时候会自动加上，保证读写的正确性
增删改查操作加MDL读锁，表结构变更操作加MDL写锁
读锁之间不互斥
读写、写写之间互斥
意向锁(Intention Locks)(InnoDB)
mysql内部使用，不需要用户干预
意向锁和行锁可以共存
作用：为了全表更新数据时的性能提升，协调行锁与表锁的关系，判断表中有没有行锁
自增锁(AUTO-INC LOCKS)
涉及AUTO_INCREMENT列的事务性插入操作时产生
行锁
作用范围：某行 或者 行之间的间隙
实现层：存储引擎
InnoDB行锁：通过给索引上的索引项加锁来实现的，只有通过索引条件检索的数据才能使用，其他将使用表锁
优点：锁定粒度最小，发生锁冲突的概率最低，并发度最高
缺点：开销大、加锁慢、会出现死锁
// 查看行锁争夺情况
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:系统启动后到现在总共等待的次数（等待总次数）
按照锁定范围划分：
记录锁（Record Locks）
锁定索引中一条记录，锁住的是索引，而不是记录本身
// 记录共享锁
select * from tblname where id = 1 lock in share mode;
// 记录排他锁
select * from tblname where id = 1 for update;
间隙锁（Gap Locks）
锁住一个索引区间（开区间，不包括双端端点）
要么锁住索引记录中间的值，要么锁住第一个索引记录前面的值或者最后一个索引记录后面的值。
作用：防止幻读，保证索引间不会被插入数据
在可重复读隔离级别下才会生效
select * from tblname where id > 4 for update;
临键锁（Next-Key Locks）
索引记录上的记录锁和在索引记录之前的间隙锁的组合（间隙锁+记录锁）（左开右闭区间）
插入意向锁（Insert Intention Locks）
做insert操作时添加的对记录id的锁。
按功能划分：
共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。
select * from tblname where ... lock in share mode;
排他锁（X）：允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的共享读锁和排他写锁。
select * from tblname where ... for update;
按照功能
共享锁Shared Locks(S锁)
加了S锁的记录，允许其他事务再加S锁，不能再加X锁
select ... lock in share mode
排他锁Exclusive Locks(X锁)
加了X锁的记录，不允许其他事务再加锁
select ... for update
死锁
两个或多个事务在同一资源上相互占用，并请求锁定对方占用的资源。锁定之后，双方都需要等待对方释放锁，同时又持有对方需要的锁，则陷入死循环。
产生死锁的情况
1、多个事务试图以不同的顺序锁定资源
2、多个事务同时锁定同一个资源
和存储引擎相关
set tx_isolation='repeatable-read';
Session_1执行：select * from account where id=1 for update;
Session_2执行：select * from account where id=2 for update;
Session_1执行：select * from account where id=2 for update;
Session_2执行：select * from account where id=1 for update;
解决死锁
1、检测到死锁的循环依赖，立即返回一个错误
2、当查询的时间达到锁等待超时的设定后放弃锁请求（不好）
3、将持有最少行级排他锁的事务进行回滚
锁优化建议
- 尽可能让所有数据检索都通过索引来完成，避免无索引行锁升级为表锁
- 合理设计索引，尽量缩小锁的范围
- 尽可能减少检索条件范围，避免间隙锁
- 尽量控制事务大小，减少锁定资源量和时间长度，涉及事务加锁的sql尽量放在事务最后执行
- 尽可能低级别事务隔离
mysqldump数据库备份
支持事务引擎（innodb）
使用–single-transaction参数，利用mvcc提供一致性视图
不会影响业务的正常运行
不支持事务引擎（MyISAM）——全局锁
使用–lock-all-tables参数
