-
序列化读写: 所有请求完全串行。 读写锁,见图。查看全部
-
问题: 多个事务,谁先谁后( 加个逻辑时间戳 ) 如何故障恢复( 日志 ) 死锁( 原因是两个线程,不同方向,相同资源 )查看全部
-
MVCC 实现写不阻塞读。 copy on write 写的时候还可以读读读。查看全部
-
所有操作序列化 -》 对共享数据加 排他锁(表级,行级)--》读写锁分离 (共享锁,排他锁)实现读读并行,即实现可重复读的隔离级别 --》 要实现读写并行,即去掉读锁(共享锁),但是就不可重复读了。查看全部
-
死锁拓展U锁:
单元事务有写锁升级为写锁,都是读锁还是读锁
查看全部 -
死锁解决方案:
避免死锁,碰撞检测,等锁超时
查看全部 -
要保证事务的安全,可以使用序列化读写:排队法。可以保证事务的安全,但是这样会把读写性能降到最低。为了提高性能有如下优化:
所以需要针对同一个事务单元进行控制。就是只需保证一个事务所涉及的数据不被访问即可,对于其他的数据可以不控制。那么对于其他事务来说,只要不操作已有事务的数据,就可以并行。
如果同时有两个或两个以上的事都是读读,那么读读之间也是可以并行的查看全部 -
单机事务调优原则
查看全部 -
重启后进入recovery模式,不能访问。查看全部
-
乐观锁查看全部
-
悲观锁查看全部
-
隔离性查看全部
-
按照我的理解:不考虑MVCC,假设没有U锁,按照讲解的理解,根据示例sql,其在数据库内部是先读锁、再写锁。这样为了保证数据是正确的,需要在可重复读的级别,这样数据更新不会错误,但是同时读的时候会出现死锁。如果在提交读的级别,同时读不会出现死锁,但是已经算是脏读了,无法保证数据更新是正确的了。使用U锁,update语句,表面上我们就可以简单认为是一个写锁了,重复读级别不会出现死锁,在提交读级别也能保证更新的正确性。u锁,其实是在读写锁的基础上,应该是在可重复读和提交读的级别上的
查看全部 -
快照读!!??!!??查看全部
-
隔离级别: 读已提交,读锁可以被写锁升级。(读读并行,读写并行,但是写读不能并行) 读 写 读 写 写 写 读 写 读未提交:只加写锁,不加读锁。(读读并行,读写并行,写读并行) 问题:可能读到写过程中的数据。 写 写 写 写 写 读 读 读查看全部
举报
0/150
提交
取消