实现一个版本控制的demo
- 1.对应的一条数据要有源可循。所以这个条数据有个ID,内容还需要有DB_TRX_ID,DB_ROLL_ID,DB_ROW_ID。事务ID好处理直接一个全局自增就可以了，ROW_ID那对当前的数据搞个自增ID,那么ROLL_ID就是上一个的ROW_ID，一个简单的数据版本就出来了，当然还需要个状态不然脏数据我们没单独处理。查询的时候我们根据版本和状态来。
- 2.再找个B+树的算法，把里面要保存的数据变成有版本的数据，这样感觉一个demo快出来了。
- 3.找的这个B+树一个都是按照度也就是叶子节点最大数做限制，这里跟数据库里面的设置的层级限制有出入（但这里我是改不动的）。
- 4.存储也是个大问题这里不做叙述，因为还没想好，这里涉及到何时刷盘的问题，还有就是你要直接堆确实也能堆但是堆的对有点耗时间感觉意义也不是很大（因为之前写过一点写读数据的，这里想了解下分布式写数据但这里又有点太难了，因为这里本身就是demo套demo的，这个demo有点难）。
- 5.一个简单的事务demo控制：可以再外面套一层锁(2PL)去操作B+树就可以了,不知道这个对不对。
- 6.大概就是开启一个事务、这个事务操作数据、然后事务提交或事务回滚。
这里说过死锁的问题
- 1.死锁的触发条件：锁需要循环互斥等待。
- 2.假如有连个锁A、B。事务1先拿A再拿B；事务2先拿B再拿A。
- 3.刚好1占了A再去拿B，2占了B再去拿A；连个谁都不释放就僵持住了，需要有一个做出点牺牲先退出。
死锁为什么不提前预警的
| 原因 | 详细解释 |
|---|---|
| 误报率极高 | 如果尝试在事务刚开始等待时就预警，会产生海量的“假警报”。例如，一个事务等几毫秒就拿到了锁，这很常见。如果为此发预警，会让运维人员麻木，失去意义。 |
| 预测模型复杂且不可靠 | 要预测未来某个事务是否会与其他事务形成死锁环，需要预知所有相关事务未来的SQL执行计划、访问的数据行、执行时间等，这在分布式、高并发环境下几乎是不可能的。 |
| 性能开销巨大 | 实时分析所有事务的潜在冲突路径，计算量呈指数级增长，会严重拖慢数据库性能，得不偿失。 |
| “预警”本身可能引入新问题 | 如果系统因为“可能死锁”就主动终止或阻塞某些事务，可能会导致正常业务被中断，甚至引发新的连锁反应。 |
