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

要是设计表的时候，主键字段设置的是数据库自增，那还能提升写入的并发吗

确定有死锁，那就排查一下死锁原因，正常情况每秒几百次的单行 update 是吃得消的

我之前在阿里做过 MySQL 内核，这种场景阿里是通过修改 MySQL 源码解决的。具体原理其实就是在 MySQL Server 层排队批量提交多个事务，InnoDB 只用拿一次行锁，提交成功之后在 Server 层构造结果。
https://github.com/alibaba/AliSQL/wiki/AliSQL-Performance-benchmark-for-inventory

AliSQL 这个源码不建议用了，没人维护的，一定要用，可以用 PolarDB-X Engine 这个代码，我走的时候还有团队在负责。

@nicoley 加分布式锁，先改缓存，缓存成功再改数据库，一致性保证就行，查询什么的走缓存，然后数据库做主主复制或者主从，再加读写分离，这样方案扩展性强，前提是技术到位再加上服务器到位，完美方案，最主要的是把数据库的读压力和写压力分开，数据库在并发读时候出现锁表问题很低，但是加上并发写就会出现，所以最终目的还是数据库读写分离加上压力在缓存层解决，完美，服务器要给力，不然是累赘这个方案

@nicoley 如果架构层次解决不了，只能改业务代码那块，那么就使用乐观锁机制，把事务内部代码减少，尽量一个事务内就是单独修改哪个金额数字，减少事务时间，再加上修改时候尽量走索引这样行锁，避免锁表，这样也可以，但是都是拆东墙补西墙方案，不是最终的，最终的还是之前架构方案

@21231sv 数据库 io 瓶颈

问题本质是热点数据写

一种思路是改用 redis 这种能抗热点修改的组件，异步落盘到 DB 。但是针对金额这种敏感字段，不建议这么做，除了需要额外维护一致性，还需要将所有读数据的场景都迁移到 redis 。

另一种思路是在数据库层面进行合并提交，类似 43 楼的的做法，需要魔改 MySQL 。热点行更新能抗几百一两千并发问题不大。

1 秒上百次的写，肯定也得 1 秒上百次读出来，纯 update 写本身毫无意义的。纯数据库方案即便各种方式写进去了，也是读不出来。比如 1 2 3 4 5 6 7 ，读出来就可能是 1 1 1 6 6 。读写都不落数据库是最好的方案，然后再搞个消息队列往数据库里塞海量的价格变动日志，供离线分析。

@CEBBCAT 感觉是和景区对接，并不是单行过百，而是该字段更新频率过百。国内这个体系的盲猜长隆集团对接

只是高频更新不会导致死锁, 建议先把死锁的问题修好再看.

@hd7771 mysql 修改源码源码上限也有限，如果是 pgsql 可以考虑用咨询锁（ advisor lock ）来降低锁开销
https://developer.aliyun.com/article/64351
https://www.modb.pro/db/48169

@lqw3030 不过如果需求是要即时读那就不满足了……