-
死锁拓展U锁：
单元事务有写锁升级为写锁，都是读锁还是读锁
查看全部 -
死锁解决方案：
避免死锁，碰撞检测，等锁超时
查看全部 -
要保证事务的安全，可以使用序列化读写：排队法。可以保证事务的安全，但是这样会把读写性能降到最低。为了提高性能有如下优化：
所以需要针对同一个事务单元进行控制。就是只需保证一个事务所涉及的数据不被访问即可，对于其他的数据可以不控制。那么对于其他事务来说，只要不操作已有事务的数据，就可以并行。
如果同时有两个或两个以上的事都是读读，那么读读之间也是可以并行的查看全部 -
总结一下 事务的隔离性是通过数据库锁的机制实现的，持久性通过redo log（重做日志）来实现，原子性和一致性通过Undo log来实现。 原文链接 https://blog.csdn.net/qq_36142146/article/details/85247960查看全部
-
ACID的概念拓展:查看全部
-
单机事务调优原则
查看全部 -
按照我的理解：不考虑MVCC，假设没有U锁，按照讲解的理解，根据示例sql，其在数据库内部是先读锁、再写锁。这样为了保证数据是正确的，需要在可重复读的级别，这样数据更新不会错误，但是同时读的时候会出现死锁。如果在提交读的级别，同时读不会出现死锁，但是已经算是脏读了，无法保证数据更新是正确的了。使用U锁，update语句，表面上我们就可以简单认为是一个写锁了，重复读级别不会出现死锁，在提交读级别也能保证更新的正确性。u锁，其实是在读写锁的基础上，应该是在可重复读和提交读的级别上的
查看全部 -
隔离性和锁的关系
查看全部 -
1.排它锁 （谁都不能进来）
序列化：什么操作都不能并行
2.读写锁 （读锁不能被升级成写锁） 不能写了当然能每次读的时候读到的数据一致
可重复读 ：读读可并行
3.读写锁 （读锁能被升级成写锁） 在读的时候能被写入数据，读到的数据就不一致了
读已提交：读读并行 读写并行
4.写锁
读未提交 ：读读并行 读写并行 写读并行
写内存
group commit
宕机重启recovery 查询日志恢复
查看全部 -
一致性：consistency，保证能看到系统内的所有更改，Can（happen before）
隔离性：以性能为理由，对一致性的破坏。
序列化读写（serializale）
排它锁
读写锁：可重复读（repeatable read），读锁不能被写锁升级，只能做到读读可并行
读已提交（read committed），读读并行，读写并行（写读还不可以并行）
读未提交（read uncommitted），只加写锁，读不加锁，可实现读读并行，读写并行，写读并行
问题：可能读到写过程中的数据
隔离性小结：SQL 92 标准定义隔离性，序列化，可重复读，读已提交，读未提交。
隔离性扩展：快照（snapshot isolation），多版本并发空知MVCC，multi-version concurrency control
查看全部 -
原子性：atomicity，一个事务要么同时成功，要么同时失败
查看全部 -
MVCC：multi-version concurrency control 多版本并发控制
能够做到：写不阻塞读
事务的先后顺序：逻辑时间戳，在oracle中用SCN，在Innodb中使用Trx_id，它仅仅是一个记录先后顺序，不是物理时间戳。
故障恢复：业务属性不匹配，系统崩溃，一般会有一个recovery点进行恢复
死锁与死锁检测：两个线程，不同方向，相同资源。即两个或多个线程，从不同方向，对同一个资源进行加锁控制，那么一定会产生死锁。
死锁解决方法：死锁避免；碰撞检测（最常用）；等锁超时；
查看全部 -
事务：锁和并发的结合体
ACID：Atomicity原子性，一致性Consistency，隔离性Isolation，持久性 Durability
排队法：序列化读写，优势：不需要冲突控制；劣势：慢速设备
排他锁：针对同一个单元的访问进行控制
读写锁：针对读读场景可以做优化
查看全部 -
网络带走的：（去中心化）；共享数据困难；贡多的延迟；确定性丧失；
去中心化的结果就是共享数据困难，需要用消息传递方式进行数据共享。但是消息传递必然存在延迟，本机中进程之间消息传递的延迟还可以忍受，但是如果是在网络中进行消息传递，则会有更多的延迟，并且有确定性数据丧失，为了降低确定性丧失数据，则需要等待更多的延迟，更可靠的传递消息协议。
查看全部 -
网络带来的：（去中心化）；理论上无限的扩展能力；理论上无限的数据安全性；理论上无限的服务可用性
查看全部 -
事务：让很多步骤操作顺序发生，多进程/线程看上去就像是一步操作
事务：方便理解，不会让计算机出现故障；但是代价是有加锁和去锁的操作
进程+数据 = 图灵机操作
查看全部
举报