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

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

为啥不用缓存

mysql 有个存储引擎叫 MEMORY

为啥你要这样做

redis

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

@opengps 成本太大了吧。

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

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

handlersocket 打错。

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

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

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

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

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

mysql+redis/memcache

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

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

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

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

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

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

队列写合并

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

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