mysql 问个问题。大神们请不吝赐教。

[netStand]

针对短时间内大量更新 mysql 数据库一张表的同一行，qps 每秒上千，有啥解决方案吗。。。。

[opengps]

必须用数据库吗？这个频率适合放在内存里。每秒上千次更新，这个应该接近普通机械硬盘的极限 iops 了

[sparrww]

为啥不用缓存

[t6attack]

mysql 有个存储引擎叫 MEMORY

[liprais]

为啥你要这样做

[zhangsen1992]

redis

[lovedebug]

这种热数据 redis 更合适吧。当然保险起见可以周期性写库。

[netStand]

@opengps 成本太大了吧。

[est]

@t6attack 不要被这名字误导了。这款引擎最大的主打特性是所有操作都会锁表。

@netStand 你可以试试 handlersocker，5.6/5.7 里叫 memcached 接口。可以把一个 InnoDB 的表映射成兼容 memcached 协议 get/set 命令，百万 qps 不是梦。

[est]

handlersocket 打错。

[ppyybb]

必须是同一行吗？这些操作实时性要求高吗（能否排队处理？）在更新期间是否有大量读操作（如果有是否要求一定是最新数据？）

如果你的场景是类似大量商品秒杀的这种场景，且必须立刻返回结果的话，且有大量读操作，且必须保证读的数据是最新的话……
我感觉就不应该使用 mysql....，这似乎到了单机处理能力的极限，而且还会有严重的竞争。
如果读操作可以不那么精确（允许一点溢出或者业务上做分段的模型处理），且拒绝使用缓存的话，那么可以尝试进行分段处理，把一行分散到多行，读的时候全部加起来返回（同时记得关掉 mysql 的 cache..）

具体业务情况不了解，以上都是我瞎想的 23333333

[nullen]

这么多请求全部打到 MySQL ？我想先问问你的具体场景。

[liuxu]

同一行，解决个 P。。。行锁都能锁死你。。。

[airdge]

mysql+redis/memcache

[hosaos]

应该先说明下是什么业务场景 应该有可以替代数据库的方案

[owenliang]

更新需要锁行，所以大概有 3 个优化方向：
1 ）能不能减少 update，比如提前聚合一下。
2 ）能不能用批量 insert 取代批量 update，这个是设计上的改变。
3 ）能不能用 LSM 类型的存储取代 mysql。

[x7395759]

楼上都说了，
1 是改程序逻辑合并数据库操作，

2 是把数据库当数据库用不要当缓存用，

3 是多看一点书多学习一下程序设计，毕竟这是一个不应该出现的问题

[realpg]

这业务场景不就是标准的 RAM based NoSQL 的最佳场景么 然后异步线程持久化到 MYSQL 即可
或者干脆用 NoSQL 自带的持久化

[jmone]

队列写合并

[yujieyu7]

数据库尽力了，还是把这个量级的并发数交给应用程序吧

[guanhui07]

redis 或 memcache 吧 更新 db 时候顺便更新缓存