MySQL 5.5 Community Server MySQL 5.6 Community Server Percona Configuration Wizard XtraBackup 搭建主从复制 Great Sites on MySQL Percona MySQL Performance Blog Severalnines 推荐管理工具 Sequel Pro phpMyAdmin 推荐书目 MySQL Cookbook
MySQL 相关项目 MariaDB Drizzle 参考文档 http://mysql-python.sourceforge.net/MySQLdb.html
MySQL 相关项目 MariaDB Drizzle 参考文档 http://mysql-python.sourceforge.net/MySQLdb.html 
这是一个创建于 427 天前的主题，其中的信息可能已经有所发展或是发生改变。
有这么一个场景 服务部署在 k8s ，服务设置的是两个 pod 。然后代码有个启动加载，会有一堆 id （假如是 a b c d e f ）去 MySQL 查询然后加载到内存。
因为两个 pod ，会同时查询等于 a 的，很可能后续同时查询等于 b 的。为了避免一个同时查询，我加了 shuffle 机制。
对于这个机制，我也是脑袋一热加的，当说出来大家讨论的时候，问会快么？我也懵逼了。
于是我写代码测试了下，逻辑是一批 id ，启动两个线程去查询，然后看耗时，结果 shuffle 的真的快一些。
对于这个结果，有人从原理上帮解析下么？或者我这个结论是错的？
因为两个 pod ，会同时查询等于 a 的，很可能后续同时查询等于 b 的。为了避免一个同时查询，我加了 shuffle 机制。
对于这个机制，我也是脑袋一热加的，当说出来大家讨论的时候，问会快么？我也懵逼了。
于是我写代码测试了下，逻辑是一批 id ，启动两个线程去查询，然后看耗时，结果 shuffle 的真的快一些。
对于这个结果，有人从原理上帮解析下么？或者我这个结论是错的？
 | 1 lucasdev 2024-10-15 14:46:10 +08:00 "shuffle 的真的快一些" 这是多少次实验的结果，排除了 MySQL 查询外的其他原因吗？建议多试几次 我瞎猜两个： 1. 查询缓存：两个并发请求没有命中缓存，错开后可以命中缓存。 2. 数据分片：a 和 b 请求落在了不同的 MySQL 节点上，避免同时竞争一台机器的资源。 当然，如果你们的 MySQL 没开查询缓存或者水平分片，这两条就不存在 |
Select Language