关于 MySQL 查询咨询

有这么一个场景服务部署在 k8s ，服务设置的是两个 pod 。然后代码有个启动加载，会有一堆 id （假如是 a b c d e f ）去 MySQL 查询然后加载到内存。

因为两个 pod ，会同时查询等于 a 的，很可能后续同时查询等于 b 的。为了避免一个同时查询，我加了 shuffle 机制。

对于这个机制，我也是脑袋一热加的，当说出来大家讨论的时候，问会快么？我也懵逼了。

于是我写代码测试了下，逻辑是一批 id ，启动两个线程去查询，然后看耗时，结果 shuffle 的真的快一些。

对于这个结果，有人从原理上帮解析下么？或者我这个结论是错的？

2 条回复

lucasdev

24 天前

"shuffle 的真的快一些" 这是多少次实验的结果，排除了 MySQL 查询外的其他原因吗？建议多试几次

我瞎猜两个：
1. 查询缓存：两个并发请求没有命中缓存，错开后可以命中缓存。
2. 数据分片：a 和 b 请求落在了不同的 MySQL 节点上，避免同时竞争一台机器的资源。

当然，如果你们的 MySQL 没开查询缓存或者水平分片，这两条就不存在

fenglangjuxu

24 天前

@lucasdev 大概 7-8 次吧期间测试也是调整了顺序。
比如第一回合先请求不 shuffle 的然后再请求 shuffle 的
第二回合先请求 shuffle 的然后再请求不 shuffle 的

第一点一般的 MySQL 应该都开启了这个
第二点用的是华为的 rds 不太清楚这点

这个测试我是再测试环境测的然后到了线上环境我是用了 shuffle 的发现总耗时比昨天的不用快了好几秒