如果同一条记录同时多个进程可能对不同的字段进行修改，怎么保证列锁？

如果同一条记录同时多个进程可能对不同的字段进行修改，怎么保证列锁？

数据库目前的锁机制有没有办法解决这种并发问题

关注者

13

被浏览

652

添加评论

分享

邀请回答

关注问题写回答

3 个回答

默认排序





郁白

分布式与数据库，秋名山公爵

5 人赞同了该回答

没听说有列锁的机制，主流的方式就是行锁。
我觉得你这种需求可以归到“热点行”优化上来，秒杀场景下的库存扣减就是最典型的“热点行”事务，有两个优化方法：第一数据库可以将可能冲突的plan放在同一个线程排队，减少锁冲突引起的唤醒和忙等代价；另外就是可以使用“early lock release”的方式，在事务确定可以提交的情况下，不等待刷redolog而提前释放行锁，使得修改同一行的多个事务，有可能在一次group commit内提交，当然前提是这是一条auto commit的事务，而非交互型事务。当时做Oceanbase0.4版本时已经实现了这两个优化。

发布于 2016-08-21

5

2 条评论

分享

收藏

感谢





江星池

主流传统数据库如Oracle、DB2之类，还不支持。 最小粒度是行锁。 不会是列锁。 即使你写了 select ... for update of col1

发布于 2016-09-22

0

添加评论

分享

收藏

感谢





机智飞

在赌场搞机器学习的程序员

谢邀。
我不敢断言目前是否有数据库实现了字段锁，但这种锁一定是非实用锁。
当我们尝试加细锁的粒度时，一定是当前的粒度无法充分应对竞态的频繁发生。字段锁可以缓解的是"多个事务修改某一记录的不同字段引起的阻塞"，而不是相同字段上的阻塞。这个时候建议题主反过来想一想，解决这个问题，一定要用字段锁吗？分表就可以了。
每一次加细锁的粒度都是对数据库存储引擎设计的挑战。一方面它极大提高了系统的复杂度，另一方面，维护细粒度锁产生的内存对象也极大地增加了系统的overhead。从表锁，页锁向行锁跨越的历史可以明确地证实这一点。
至于如何实现字段锁，我提出两个问题给题主用来思考。
1、对于请求修改两个不同变长字段的事务A,B来说，它们之间一定不会彼此阻塞吗？
2、两个事务并发修改不同字段时，系统宕机，如何回滚？回滚时都需要哪些数据结构？

发布于 2016-08-21

0

收起评论

分享

收藏

感谢

5 条评论

切换为时间排序


知乎用户 (提问者)1
年前

这个需求不是我现实开发中刚遇到的，是一个面试中被问到，当时没回答上来，后来自己思考了一下也没想到好办法。被你这么一分析，确实就算有这个列锁也不一定就是利大于弊的事情。第一个问题可以通过设计来避免，第二个暂时想不到，要么就相关事务全部回滚。

赞
回复
踩
举报





机智飞 (作者) 回复知乎用户 (提问者)1
年前

我提问题的目的就是"你瞧，加了字段锁效率反而更低"。另外，第二个问题，需要增加字段锁表，字段锁实例，日志项等数据结构，而且有额外数据结构就要有额外算法支持。对于实现通用字段锁这个需求，个人感觉系统复杂度已经不在可控范围了。

赞
查看对话
回复
踩
举报


知乎用户 (提问者) 回复机智飞 (作者)1
年前

那在你看来，如果面试遇到这种问题，比较好的回答应该是什么

赞
查看对话
回复
踩
举报





机智飞 (作者)1
年前

这种做法不现实，原因是blablabla，alternatives可以有分表，……等等

赞
回复
踩
举报


知乎用户 (提问者) 回复机智飞 (作者)1
年前

好，多谢你的 回答。

赞