没命中索引才会去去锁表

code 有启动参数么，如果有的话，看看这块两边是不是一致

提供个思路，A，B 服务做好接口幂等性，出现 timeout 或者失败的 case 原地重试，兜底定时任务查补单，还有问题的人工处理，这样能干掉 99.9%的问题。

@sagaxu 楼主这里有明确的 userId，这种情况不需要查全量的索引，这种只要 hash 一下 userId 确定哪个表好了吧，这种时候索引量就是 1/n，io 也少了
如果要全表扫描分库分表的方案很难做罢了，只能借助于 hive

***Request
***Response

Golang :)

@sagaxu 索引键合理的话，千万条以下可以 3 次 io 。
5 次 io 到 3 次 io 要分几千个表，是线上业务中没有走过这块逻辑吧？这种情况下简单分 101 个表就足够了，亿级别数据直接降到百万，不知道你几千个表怎么算出来的。

极端情况不用提了，没啥意义

@sagaxu 大索引命中单条数据硬盘 io 次数不一样吧，一般来讲，按照 mysql 的 b+树， 百万数据 3 次 io，千万数据 4 次 io 了。亿级别的数据 5 次 io

总量没有减少，但是你查询只会落到分片上，不会走所有索引啊。5 次 io 减少到 3 次 io 提升已经很明显了好吧

@sagaxu 多一个哈希和取模能有啥开销？百万级数据量查询和亿级别查询，就算命中索引耗费的时间远大于哈希取模。

如果耗时 10ms 内可以不用优化。pct99 一直不稳的话可以考虑分库分表

按照门店 id 分库分表，水平拆分到 101 个库里，表变为逻辑表，单表 18w 数据

我来当分子了

从不清洁

这就是尴尬的地方了，在之前公司开年会的时候，抽奖环节大家都会要求现场 code review 的，所以比较和谐🐶

钛 d b

公司电脑随便戳
自己的电脑不要在公司用不就完事了

@callmexiaodeng 我之前也是这么想的，买了个手托垫着，结果发现又太高了，反而不舒服，现在不用手托在用着。

@Virace 太久不用薄膜，我也不知道薄膜啥手感了😂

niz plum 35g 版本，灰常好用。手感会有些肉，触底有缓冲的感觉。我主观感觉手感 niz > 樱桃静音红 > hhkb

115 下载单个文件也限速的，10M 左右就到顶了