数据库高频更新问题 谁遇到过没 有啥好的解决方案部

设计的就有问题，为啥都要并发修改在数据库层面，正常不是缓存层面加锁控制数量金额等，业务交互在数据库之前走完了，数据库只是记录最终结果。然后再改数据库，而不是直接操作数据库，任何性能问题都是架构层面的问题，不是改个啥代码能解决的，除非屎山代码

@miaomiaotu Redis 不是单线程执行的吗，为什么要在缓存层面加锁控制？如果确实要做业务流程编排，感觉可以把这部分的控制放到 Lua 脚本里面去控制。

@miaomiaotu 再就是 Redis 和 数据库数据的一致性该如何保证咧 ？ 就是存在 Redis 挂了的情况？

好奇是什么场景

@godall 更新改为插入新记录无法解决并发写入的一致性问题吧：UPDATE SET val+10 ，这个 val 怎么确保是最新记录呢？

@coderzhangsan 如果实时读取需求不强，用消息队列是个好办法。

用 hazelcast 或 redis

用 redis 然后 定期刷入 db

更新上百次，也是不同的记录吧？理论上是不会卡死的啊？
是不是更新字段没走索引啊

#29 更新的 where 条件没走索引，造成锁表了

把你的问题拿去问 deepseek R1 ， 给的答案比评论区大部分方案靠谱。

同一个字段没关系，不是同一行的就没问题，降低锁的粒，表到行到页。前提能准确定位，又不产生共享锁。

业务场景描述太过有限

说白了就是避免行锁，那只能参考数据库的 latch 和 children latch 设计

即将一行尽量拆分成多行

比如 100 块资源池，拆分成 4 行，每行 25 块

不考虑 delete/insert 的话，纯 update 随机一行

如果只是一味的累加，风险不大

否则可能遭遇负数风险，就要引入全局锁定读

所以还得看场景！看场景！看场景！

肯定是股票~期货~外汇~数字货币呗，报价随买卖单对挂单的撮合而动，mysql 做不到的，直接用缓存之类的放内存里面。

将多次 update 的行锁请求合并到一次上。比如启动一个异步线程和引入一个时间窗口，对这个窗口内的所有请求扣减金额进行相加，进行一次 update 。然后进行多次 insert 操作记录扣减日志，发生异常根据日志情况进行回滚

@Asheet 如果合并请求后预计总共扣减的金额和超过了表里面这个字段上的值，那该怎么处理

@nicoley #36 这种情况下退化成串行扣减

换一个技术牛逼点的架构师

@mark2025 #25 楼主想表达的可能是引入“账单”概念，以此把并发 update 写转化为并发 insert ，从根源上规避了高并发操作同一行的场景，计算余额对所有操作行做累加即可

@21231sv 更新同一行，行级别的排他锁