如果同一条记录同时多个进程可能对不同的字段进行修改,怎么保证列锁?
数据库目前的锁机制有没有办法解决这种并发问题
关注者
13
被浏览
652
3 个回答
分布式与数据库,秋名山公爵
没听说有列锁的机制,主流的方式就是行锁。
我觉得你这种需求可以归到“热点行”优化上来,秒杀场景下的库存扣减就是最典型的“热点行”事务,有两个优化方法:第一数据库可以将可能冲突的plan放在同一个线程排队,减少锁冲突引起的唤醒和忙等代价;另外就是可以使用“early lock release”的方式,在事务确定可以提交的情况下,不等待刷redolog而提前释放行锁,使得修改同一行的多个事务,有可能在一次group commit内提交,当然前提是这是一条auto commit的事务,而非交互型事务。当时做Oceanbase0.4版本时已经实现了这两个优化。
在赌场搞机器学习的程序员
谢邀。
我不敢断言目前是否有数据库实现了字段锁,但这种锁一定是非实用锁。
当我们尝试加细锁的粒度时,一定是当前的粒度无法充分应对竞态的频繁发生。字段锁可以缓解的是"多个事务修改某一记录的不同字段引起的阻塞",而不是相同字段上的阻塞。这个时候建议题主反过来想一想,解决这个问题,一定要用字段锁吗?分表就可以了。
每一次加细锁的粒度都是对数据库存储引擎设计的挑战。一方面它极大提高了系统的复杂度,另一方面,维护细粒度锁产生的内存对象也极大地增加了系统的overhead。从表锁,页锁向行锁跨越的历史可以明确地证实这一点。
至于如何实现字段锁,我提出两个问题给题主用来思考。
1、对于请求修改两个不同变长字段的事务A,B来说,它们之间一定不会彼此阻塞吗?
2、两个事务并发修改不同字段时,系统宕机,如何回滚?回滚时都需要哪些数据结构?
5 条评论