-
隔离性查看全部
-
快照读！！？？！！？？查看全部
-
隔离级别： 读已提交，读锁可以被写锁升级。（读读并行，读写并行，但是写读不能并行） 读 写 读 写 写 写 读 写 读未提交：只加写锁，不加读锁。（读读并行，读写并行，写读并行） 问题：可能读到写过程中的数据。 写 写 写 写 写 读 读 读查看全部
-
事务处理 多个事务单元谁先谁后？ 业务属性不匹配（条件不满足） 系统崩溃（事务没有执行结束） 死锁与死锁检测查看全部
-
事务-MVCC 写读场景的优化 写锁上允许并发读。查看全部
-
事务的核心：锁，并发。 事务单元之间的happen-before关系： 读写，写读，读读，写写 序列化读写： 事务排队 优化- 排他锁 （两个事务两个队列） 再优化 - 读写锁 （实现读并行，读写不并行，实现可重复读） 再优化 - 读写锁 （实现读并行，读写并行，写锁取代读锁）查看全部
-
事务单元之间的关系查看全部
-
这就是生活查看全部
-
将读锁和写锁分开定义，让读并行，其他的三种方式RW，WR，WW串行查看全部
-
加排它锁，并行处理无冲突的事务，串行执行有数据冲突的事务查看全部
-
串行方式执行事务查看全部
-
时间戳分为： 逻辑时间戳和 物理时间戳， 逻辑时间戳只用来表示先后关系查看全部
-
Good查看全部
-
单机事务异常应对 回滚 系统down机：进入recovery模式，将提交后的事务单元继续完成，未提交完成的回滚重新提交 调优原则 减少锁的覆盖范围 增加锁上可并行的线程数 选择正确锁类型：悲观锁，使线程到blocking状态，通知信息ok的状态切换回等待状态，缺点是需要数据换入换出，适合并发争抢严重的场景；乐观锁，适合并发争抢不太严重的场景查看全部
-
1、多个事务的先后：SCN（oracle），TRX_id（Innodb），通过一个版本号的前后来区分操作的前后，是逻辑时间戳。 2、故障恢复：既是A原子性，事务回滚。当前事务的反向操作。系统崩溃时，在做数据回滚时，数据恢复时，不能让外部看见你的信息。 3、死锁与死锁检测：产生原因，当三个同时发生时，1、两个线程2,、不同方向3、相同资源。 4、死锁的解决方法;1、尽可能不死锁2、碰撞检测（通常用这个）（记录事务锁的状态）3、等锁超时（如果锁时间超过某个时间，直接抛错）查看全部
举报
0/150
提交
取消