1
opengps 2018 年 7 月 25 日 via Android
必须用数据库吗?这个频率适合放在内存里。每秒上千次更新,这个应该接近普通机械硬盘的极限 iops 了
|
2
sparrww 2018 年 7 月 25 日
为啥不用缓存
|
3
t6attack 2018 年 7 月 25 日
mysql 有个存储引擎叫 MEMORY
|
4
F281M6Dh8DXpD1g2 2018 年 7 月 25 日
为啥你要这样做
|
5
zhangsen1992 2018 年 7 月 25 日
redis
|
6
lovedebug 2018 年 7 月 25 日 via Android
这种热数据 redis 更合适吧。当然保险起见可以周期性写库。
|
8
est 2018 年 7 月 25 日
|
9
est 2018 年 7 月 25 日
handlersocket 打错。
|
10
ppyybb 2018 年 7 月 25 日 via iPhone
必须是同一行吗?这些操作实时性要求高吗(能否排队处理?)在更新期间是否有大量读操作(如果有是否要求一定是最新数据?)
如果你的场景是类似大量商品秒杀的这种场景,且必须立刻返回结果的话,且有大量读操作,且必须保证读的数据是最新的话…… 我感觉就不应该使用 mysql....,这似乎到了单机处理能力的极限,而且还会有严重的竞争。 如果读操作可以不那么精确(允许一点溢出或者业务上做分段的模型处理),且拒绝使用缓存的话,那么可以尝试进行分段处理,把一行分散到多行,读的时候全部加起来返回(同时记得关掉 mysql 的 cache..) 具体业务情况不了解,以上都是我瞎想的 23333333 |
11
nullen 2018 年 7 月 25 日
这么多请求全部打到 MySQL ?我想先问问你的具体场景。
|
12
liuxu 2018 年 7 月 25 日
同一行,解决个 P。。。行锁都能锁死你。。。
|
13
airdge 2018 年 7 月 25 日
mysql+redis/memcache
|
14
hosaos 2018 年 7 月 25 日
应该先说明下是什么业务场景 应该有可以替代数据库的方案
|
15
owenliang 2018 年 7 月 25 日
更新需要锁行,所以大概有 3 个优化方向:
1 )能不能减少 update,比如提前聚合一下。 2 )能不能用批量 insert 取代批量 update,这个是设计上的改变。 3 )能不能用 LSM 类型的存储取代 mysql。 |
16
quickma 2018 年 7 月 25 日
楼上都说了,
1 是改程序逻辑合并数据库操作, 2 是把数据库当数据库用不要当缓存用, 3 是多看一点书多学习一下程序设计,毕竟这是一个不应该出现的问题 |
17
realpg PRO 这业务场景不就是标准的 RAM based NoSQL 的最佳场景么 然后异步线程持久化到 MYSQL 即可
或者干脆用 NoSQL 自带的持久化 |
18
jmone 2018 年 7 月 26 日
队列写合并
|
19
yujieyu7 2018 年 7 月 26 日 via iPhone
数据库尽力了,还是把这个量级的并发数交给应用程序吧
|
20
guanhui07 2018 年 7 月 26 日
redis 或 memcache 吧 更新 db 时候顺便更新缓存
|