工厂的网站在哪里做的,wordpress手机验证码登录,微信开发网站开发,宁波seo哪家好推广前几天项目上合作公司的系统出现了一次死锁#xff0c;突然想到由于近几年开发设计的系统并发用户比较少#xff0c;很久没有碰到过死锁了#xff0c;因此对死锁的概念也比较生疏了#xff0c;需要温习一下。
事务
先从最基本的概念开始#xff0c;事务、及其ACID特性。…前几天项目上合作公司的系统出现了一次死锁突然想到由于近几年开发设计的系统并发用户比较少很久没有碰到过死锁了因此对死锁的概念也比较生疏了需要温习一下。
事务
先从最基本的概念开始事务、及其ACID特性。
事务的概念就用一句话概括事务中的SQL语句要么全部执行成功要么全部执行失败。
Atomicity原子性一个事务必须被视为不可分割的工作单元整个事务中的所有操作要么全部提交成功要么全部失败回滚。对于一个事务来说不能只执行其中的一部分操作这就是事务的原子性。
Consistency一致性事务可以确保数据总是从一个一致性状态转换到另一个一致性状态。
Isolation隔离性事务隔离性的目的是要确保一个事务所做的修改在最终提交之前对其他事务是不可见的。这一点其实是很难做到的所以才有了iso level隔离级别的概念。
Durability持久性一旦事务提交修改就会永久保存在数据库中。
隔离级别
SQL标准定义了四种隔离级别 READ UNCOMMITTED未提交读 事务中的修改即使没有提交其他事务中也是能看见的。事务能够读取未提交数据也被称之为“脏读”dirty read。这个级别会导致很多问题从性能上来说READ UNCOMMITTED不对比其他级别好太多。但却缺乏其他级别的很多好处除非真的有非常必要的理由在实际应用中一般很少使用。
*** READ COMMITTED(提交读 *** 大部分数据库SQL Server/Oracle等默认的隔离级别但Mysql不是。一个事务开始后只能看到其他事务已经提交的修改。READ COMMITTED避免了脏读但是READ COMMITTED不可重复读nonrepeatable read因为在一个事务中两次执行同样的查询可能会读到不一样的结果。
REPEATABLE READ可重复读 可重复读确保了在一个事务中多次读取同样记录的结果是一致的。但是在理论上REPEATABLE READ还是无法解决另外一个幻读phantom read的问题。幻读指的是某个事务在读取某个范围内的记录时另一个事务又在该范围内插入了新的记录当之前的事务再次读取该范围内的数据时会产生幻行phantom row。InnoDB和XtraDB存储引擎通过引入MVCC解决了幻读问题。
可重复读是MySql默认的隔离级别。
SERIALIZABLE串行化 最高隔离级别通过强制事务串行执行避免幻读问题。简单来说RERIALIZABLE会在读取的每一行数据上加锁所以可能会导致大量的超时和锁争夺问题实际应用中很少用这个隔离级别。 死锁
死锁指的是两个或多个事务在统一资源上的相互占用并请求锁定对方占用的资源从而导致恶性循环的现象。
当多个事务试图以不同顺序锁定资源时就可能产生死锁多个事务同时锁定同一个资源时也可能产生死锁。
比如事务一
start transaction;
update stock set price1.2 where id3;
update stock set price1.5 where id4;
commit;事务二
start transaction;
update stock set price1.2 where id4;
update stock set price1.5 where id3;
commit;如果事务一执行了第一条update语句、锁定了第一条数据、事务二也执行了第一条update语句、锁定了第一条数据此时两个事务准备执行第二条语句是发现已经被对方锁定彼此等待对方释放锁资源、同时又持有对方等待的锁资源这样就陷入了死循环造成死锁。
死锁发生后必须有第三方介入才可能解除。比如大部分的数据库都设置了等待的timeout时长超过该时长后事务会主动放弃等待InnoDB引擎将持有最少行级排它锁的事务回滚、rollback事务。
死锁是事务性数据库系统中不可避免的现象我们可以认为死锁其实是数据一致性的一种保护性措施但是我们在设计应用的时候还是要在充分理解死锁底层逻辑的前提下尽可能避免死锁的发生。
MVCC
MVCC是multi-version concurrency control的缩写意思是多版本并发控制。多版本并发控制是尽可能避免加锁操作而实现数据库的ACID因此开销更低。
MVCC是通过保存数据在某一个时间点的快照来实现的也就是说不管执行多长时间每个事务看到的数据是一致的。根据事务开始时间的不同每个事务对同一张表同一时刻看到的数据可能是不一样的。
MVCC没有统一的实现标准不同存储引擎的MVCC实现是不同的。
InnoDB的MVCC实现的简化版行为
InnoDB的每行记录后面保存两个隐藏的列一个保存行的创建时间、一个保存行的删除时间。但是实际记录的并不是时间而是版本号。
没开始一个新的事务版本号会自动递增事务开始时刻的系统版本号会作为事务的版本号用来和查询到的每行版本号作比较。
在REPEATABLE READ隔离级别下
SELECT操作InnoDB会以下两个条件检查每行记录
只查找版本早于当前事务版本号的数据行也就是行的系统版本号小于等于事务的系统版本号这样可以确保事务读取的数据行要么是事务开始前已经存在的要么是当前事务插入或修改过的。行的删除版本要么未定义要么大于当前事务版本号。这可以确保事务读到到的行在事务开始之前未删除。
INSERT操作 为插入的每一行保存当前事务的系统版本号作为行版本号。 DELETE操作 为删除的每一行保存当前事务的系统版本号作为行的删除标识。 UPDATE操作 插入一条新纪录保存当前事务版本号作为行版本号同时保存当前事务版本号到原有行作为删除标识。
MVCC机制可以确保在大多数情况下的读操作都不需要加锁使得读数据操作很简单、性能更好并且能确保读取到符合标准的数据。不足之处是每行记录都需要额外的空间并且要做更多的检查工作以及一些额外的维护工作。
MVCC只在REPEATABLE READ和READ COMMITTED 两个隔离级别下工作。其他两个隔离级别都和MVCC不兼容。
