gpt4 book ai didi

mysql - Go 的连续 MySQL 查询在某个时间点后变得更慢

转载 作者:IT王子 更新时间:2023-10-29 02:23:58 24 4
gpt4 key购买 nike

我正在用 go 编写一个作业,它遍历一些 MySQL 表,根据一些条件选择一些行,从中提取电子邮件地址并向每个人发送一封电子邮件。

过滤过程会查看一个表(我们称它为存储),它非常大(已转储约 6gb),如下所示:

Columns:
id varchar(64) PK
path varchar(64) PK
game varchar(64)
guid varchar(64)
value varchar(512)
timestamp timestamp

有两个索引:(id, path)(如上所示的 PK)和 guid

作业首先从一个表中检索一长串 guid,然后对它们进行批处理并在 storage 表上执行连续查询:

SELECT guid, timestamp FROM storage 
WHERE game = 'somegame'
AND path = 'path' AND value = 'value' AND timestamp >= '2015-04-22 00:00:00.0' AND timestamp <= '2015-04-29T14:53:07+02:00'
AND guid IN ( ... )

其中 IN 子句包含一个 guid 列表。

我需要检索时间戳才能进一步过滤。

当针对我的本地 MySQL 运行时,一切都按预期工作,查询大约需要 180 毫秒,批处理为 1000 个 guid。

当针对 Amazon RDS 上的同一个数据库运行时,查询很快开始,但在某个时间点之后,它们突然开始耗时大约 30 秒,并一直持续到作业结束。

我尝试了很多方法来解决这个问题,但无法找出原因。一些注意事项:

  • 该作业仅使用一个sql.DB 对象。另外,我准备了一次上述声明并大量重复使用它。
  • 起初,我以为是因为 RDS 数据库运行的是 MySQL 5.5,而我运行的是 5.6。我制作了一个 RDS 数据库的副本,升级到 5.6,再次运行该作业。问题再次发生。
  • 两个数据库中的数据量相同:我转储了生产数据库并将其导入到我的本地数据库中并运行了作业。相同的行为(它仍然在本地快速运行)。
  • RDS 节点的 AWS 监控没有显示任何明显的峰值。 CPU 使用率从 1% 跃升至 10%,作业似乎只打开了几个连接 (~4)。
  • 我让一位同事在他们的 PC 上运行这项工作,指向我的 MySQL 数据库,只是为了确保出色的性能并非源于本地连接这一事实。它的运行速度与在我的 PC 上一样快(诚然,通过 LAN)。
  • 从我的本地 PCAmazon EC2 节点运行了针对 RDS 的作业,后者非常接近 RDS。从EC2开始,表现更好,但问题还是出现了。
  • 这项工作是高度并发的,每一步都有输入和输出 channel (缓冲区大小为 1000),工作由 goroutines 执行。在这些步骤之间,我有其他 goroutines 对前一个 goroutine 的输出进行批处理。
  • 减速是突然的,一个查询需要几毫秒,而下一个查询需要几十秒。

我完全不知道为什么会这样。任何建议,将不胜感激。

最佳答案

因此,经过大量试验后,我找到了解决方案。

我在涉及的 RDS 实例上使用 Magnetic Storage,它保证大约 100 IOPS。这限制了我们查询数据的速度。

我使用 2000 Provisioned IOPS 进行了测试,作业一路跑的很快。

关于mysql - Go 的连续 MySQL 查询在某个时间点后变得更慢,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/30098335/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com