锁是需要事务结束后才释放的。
一个是 MVCC,一个是两阶段锁协议。
为什么要并发控制呢?是因为多个用户同时 *** 作 MySQL 的时候,为了提高并发性能并且要求如同多个用户的请求过来之后如同串行执行的一样(为了解决脏读、不可重复读、幻读)
官方定义:
两阶段锁协议是指所有事务必须分两个阶段对数据加锁和解锁,在对任何数据进行读、写 *** 作之前,事务首先要获得对该数据的封锁;在释放一个封锁之后,事务不再申请和获得任何其他封锁。
对应到 MySQL 上分为两个阶段:
但是两阶段锁协议不要求事务必须一次将所有需要使用的数据加锁(innodb在需要的索引列数据才锁行),并且在加锁阶段没有顺序要求,所以这种并发控制方式会形成死锁。
MySQL有两种死锁处理方式:
死锁检测 (默认开启)
死锁检测的原理是构建一个以事务为顶点、锁为边的有向图,判断有向图是否存在环,存在即有死锁。
回滚
检测到死锁之后,选择插入更新或者删除的行数最少的事务回滚,基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段来判断。
收集死锁信息:
减少死锁:
死锁解决:
一、show ENGINE INNODB status查看死锁位置,分析。
二、
首先解决死锁可以从死锁发生的条件入手,最容易解决的就是更改获取资源的顺序;
其次是避免长事务,让事务执行的时间尽可能少,让事务的覆盖范围尽可能小,长事务会导致并发度降低,且会有更多的SQL查 询延迟;
给整个方法加事务是否是必须的?可以不加事务的尽量不加。
第一步,查出已锁的进程
查看正在锁的事务
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS
``
查看等待锁的事务
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS
``
INNODB_TRX表主要是包含了正在InnoDB引擎中执行的所有事务的信息,包括waiting for a lock和running的事务
select * from information_schema.innodb_trx
``
第二步,kill进程
show engin innodb status //最后一次死锁信息及sql
show open tables where in_use >0 //查看锁表
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)