mysql 表机制

锁的认识

1.1 锁的解释

计算机协调多个进程或线程并发访问某一资源的机制。

1.2 锁的重要性

在数据库中，除传统计算资源（CPU、RAM、I\O等）的争抢，数据也是一种供多用户共享的资源。 如何保证数据并发访问的一致性，有效性，是所有数据库必须要解决的问题。 锁冲突也是影响数据库并发访问性能的一个重要因素，因此锁对数据库尤其重要。

1.3 锁的缺点

加锁是消耗资源的，锁的各种操作，包括获得锁、检测锁是否已解除、释放锁等 ，都会增加系统的开销。

1.4 简单的例子

现如今网购已经特别普遍了，比如淘宝双十一活动，当天的人流量是千万及亿级别的，但商家的库存是有限的。 系统为了保证商家的商品库存不发生超卖现象，会对商品的库存进行锁控制。当有用户正在下单某款商品最后一件时， 系统会立马对该件商品进行锁定，防止其他用户也重复下单，直到支付动作完成才会释放（支付成功则立即减库存售罄，支付失败则立即释放）。

锁的类型

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） 允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁

写锁（write lock），也叫排他锁（exclusive lock） 允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的共享锁和排他锁

特点存储引擎默认锁

InnoDB

1. 对一行数据加锁 2. 开销大 3. 加锁慢 4. 会出现死锁 5. 锁粒度小，发生锁冲突概率最低，并发性高

事务并发带来的问题

1. 更新丢失 解决：让事务变成串行操作，而不是并发的操作，即对每个事务开始---对读取记录加排他锁 2. 脏读 解决：隔离级别为Read uncommitted 3. 不可重读 解决：使用Next-Key Lock算法来避免 4. 幻读 解决：间隙锁（Gap Lock） 事务并发带来的问题 脏读 最容易理解。另一个事务修改了数据，但尚未提交，而本事务中的SELECT会读到这些未被提交的数据。 假如，中午去食堂打饭吃，看到一个座位被同学小Q占上了，就认为这个座位被占去了，就转身去找其他的座位。不料，这个同学小Q起身走了。事实：该同学小Q只是临时坐了一小下，并未“提交”。 不重复读 同样是两个事务在操作同一数据，如果在事务开始时读了某数据，这时候另一个事务修改了这条数据，等事务再去读这条数据的时候发现已经变了，先后两次读到的数据结果不一致，这就是没办法重复读一条数据。 假如，中午去食堂打饭吃，看到一个座位是空的，便屁颠屁颠的去打饭，回来后却发现这个座位却被同学小Q占去了。 幻读 事务一开始按某个查询条件没查出任何数据，结果因为另一个事务的影响，再去查时却查到了数据，这种就像产生幻觉了一样，被称作幻读。 假如，中午去食堂打饭吃，看到一个座位是空的，便屁颠屁颠的去打饭，回来后，发现这些座位都还是空的（重复读），窃喜。走到跟前刚准备坐下时，却惊现一个恐龙妹，严重影响食欲。仿佛之前看到的空座位是“幻影”一样。

2.3 事务的四种隔离级别

MySQL InnoDB事务的隔离级别有四级，默认是“可重复读”（REPEATABLE READ）。

未提交读（READ UNCOMMITTED）

读未提交其实就是事务没提交就可以读，很显然这种隔离级别会导致读到别的还没提交的数据，一旦基于读到的数据做了进一步处理，而另一个事务最终回滚了操作，那么数据就会错乱，而且很难追踪。总的来说说，读未提交级别会导致脏读。

另一个事务修改了数据，但尚未提交，而本事务中的SELECT会读到这些未被提交的数据（脏读）。

提交读（READ COMMITTED）

务提交后才能读，假设你拿着银行卡去消费，付钱之前你看到卡里有2000元，这个时候你老婆在淘宝购物，赶在你前面完成了支付，这个时候你再支付的时候就提示余额不足，但是分明你看到卡里的钱是够的啊。

这就是两个事务在执行时，事务A一开始读取了卡里有2000元，这个时候事务B把卡里的钱花完了，事务A最终再确认余额的时候发现卡里已经没有钱了。很显然，读提交能解决脏读问题，但是解决不了不可重复读。

本事务读取到的是最新的数据（其他事务提交后的）。问题是，在同一个事务里，前后两次相同的SELECT会读到不同的结果（不重复读）。

（默认）可重复读（REPEATABLE READ）

解决不可重复读问题，事务A一旦开始执行，无论事务B怎么改数据，事务A永远读到的就是它刚开始读的值。那么问题就来了，假设事务B把id为1的数据改成了2，事务A并不知道id发生了变化，当事务A新增数据的时候却发现为2的id已经存在了，这就是幻读。

在同一个事务里，SELECT的结果是事务开始时时间点的状态，因此，同样的SELECT操作读到的结果会是一致的。但是，会有幻读现象（幻读）。

串行化（SERIALIZABLE）

所有的事务串起来一个个执行，因为没有并发的场景出现了，什么幻读、脏读、不可重复读统统都不存在的。但是同样的，基本并发能力会非常差。

读操作会隐式获取共享锁，可以保证不同事务间的互斥。

如何上锁？

3.1 表锁

隐式上锁（默认，自动加锁自动释放）

select //上读锁

insert、update、delete //上写锁

显式上锁（手动）

lock table tableName read;//读锁 lock table tableName write;//写锁

解锁（手动）

unlock tables;//所有锁表

session01	session02
lock table teacher read;//上读锁
select * from teacher; //可以正常读取	select * from teacher;//可以正常读取
update teacher set name = 3 where id =2;//报错因被上读锁不能写操作	update teacher set name = 3 where id =2;//被阻塞
unlock tables;//解锁
	update teacher set name = 3 where id =2;//更新操作成功

session01	session02
lock table teacher write;//上写锁
select * from teacher; //可以正常读取	select * from teacher;//被阻塞
update teacher set name = 3 where id =2;//可以正常更新操作	update teacher set name = 4 where id =2;//被阻塞
unlock tables;//解锁
	select * from teacher;//读取成功
	update teacher set name = 4 where id =2;//更新操作成功

3.2 行锁

隐式上锁（默认，自动加锁自动释放）

select //不会上锁

insert、update、delete //上写锁

显式上锁（手动）

select * from tableName lock in share mode;//读锁 select * from tableName for update;//写锁

解锁（手动）

1. 提交事务（commit） 2. 回滚事务（rollback） 3. kill 阻塞进程

session01	session02
begin;
select * from teacher where id = 2 lock in share mode;//上读锁
	select * from teacher where id = 2;//可以正常读取
update teacher set name = 3 where id =2;// 可以更新操作	update teacher set name = 5 where id =2;//被阻塞
commit;
	update teacher set name = 5 where id =2;//更新操作成功

session01	session02
begin;
select * from teacher where id = 2 for update;//上写锁
	select * from teacher where id = 2;//可以正常读取
update teacher set name = 3 where id =2;// 可以更新操作	update teacher set name = 5 where id =2;//被阻塞
rollback;
	update teacher set name = 5 where id =2;//更新操作成功

为什么上了写锁，别的事务还可以读操作？ 因为InnoDB有MVCC机制（多版本并发控制），可以使用快照读，而不会被阻塞。

4 行锁的注意点

1. 只有通过索引条件检索数据时，InnoDB才会使用行级锁，否则会使用表级锁(索引失效，行锁变表锁) 2. 即使是访问不同行的记录，如果使用的是相同的索引键，会发生锁冲突 3. 如果数据表建有多个索引时，可以通过不同的索引锁定不同的行

如何排查锁？

5.1 表锁

查看表锁情况

1	show open tables;

表锁分析

1	show status like 'table%';

1. table_locks_waited 出现表级锁定争用而发生等待的次数（不能立即获取锁的次数，每等待一次值加1），此值高说明存在着较严重的表级锁争用情况 2. table_locks_immediate 产生表级锁定次数，不是可以立即获取锁的查询次数，每立即获取锁加1

5.2 行锁

行锁分析

1	show status like 'innodb_row_lock%';

1. innodb_row_lock_current_waits //当前正在等待锁定的数量 2. innodb_row_lock_time //从系统启动到现在锁定总时间长度 3. innodb_row_lock_time_avg //每次等待所花平均时间 4. innodb_row_lock_time_max //从系统启动到现在等待最长的一次所花时间 5. innodb_row_lock_waits //系统启动后到现在总共等待的次数

死锁

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

乐观锁与悲观锁

7.1 悲观锁

解释

假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作

实现机制

表锁、行锁等

实现层面

数据库本身

适用场景

并发量大

7.2 乐观锁

解释

假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性

实现机制

提交更新时检查版本号或者时间戳是否符合

实现层面

业务代码

适用场景

并发量小

8.select … for update查询
select查询是不加锁的，select…for update是会加锁的，而且是悲观锁，但是在不同查询条件时候加的锁的类型（行锁，表锁）是不同的。

select * from t_user where id = 1 for update；

原由：
在where 后面查询条件是主键索引，唯一索引时候是行锁
查询条件是普通字段时候加的是表锁

9.自己容易忘的命令

1. 开启事务：start transaction ;
2. 悲观锁：select user_id ,user_name from huixin where user_id=1002 for update ;
3. 提交事务： commit ;
4. 查看当前锁：show open tables where In_use >0;
5. 清空所有锁：unlock tables;
6. 设置事务的提交：set autocommit = (off/0) 或 set autocommit =( on/1)
7. 查看事务是否自动提交： show variables like ‘autocommit’
8. 回滚事务：rollback