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