MySQL 瓶颈

Question

我有一个具有以下结构的表:

ID, SourceID, EventId, Starttime, Stoptime

所有 ID 列都是 char(36)，时间是日期。

问题是查询表真的很慢。我有 7 百万行，我有大约 60-70 个线程一直在向表写入(插入或更新)。

另一方面，我有需要从该表中读取的 GUI，它在这里变得很慢。如果我想选择所有已创建的事件 where SourceID = something 则需要将近 300 秒。 SourceID 有一个索引。我采用相同的查询并将解释关键字放在首位，我得到了这个。

select type = simple
type = ref
possible_keys = sourceidnevent,sourceid
key = soruceid
key_len = 109
ref = const
rows = 84148

和查询

SELECT * FROM tabel where sourceid='28B791C7-D519-4F0C-BC03-EFB1D4AC9CEB'

然而，我开始思考我真正需要的是什么。我想知道哪个事件发生在哪个服务器上，以及哪个事件发生在服务器上，按日期排序。我为使用where 和order by 的所有组合添加了索引。

我需要所有行，因为我想对它们进行一些计算、一些分组、avarage 等等。但我是在 .NET 环境中做的，而不是问很多问题。

但是，如果我对选择添加限制，它会更快。那么瓶颈是传输的数据量，而不是 查找/选择部分？如果是这样，我可以重建我的应用程序以仅在一天内进行计算并将结果保存到另一个表中，然后汇总所有结果。

我怎样才能加快这个过程？切换到 MongoDB 会更好吗？我目前使用 MySQL 和 InnoDB。

Answer 1

有很多信息您没有在这里提供 - 其中一些我在其他地方的评论中提到过。

NoSQL 在单个节点上不太可能比 MySQL 快很多。如果它比使用 handler API 更快，我会感到非常惊讶在 MySQL 上以及适当的索引。

您提供了解释计划的一部分(但不是正在解释的查询)- 但您没有提供对此的任何解释:

rows = 84148

它真的需要处理那么多行才能提供您需要的结果吗？如果是这样并且结果没有聚合，那么您可能需要考虑为什么需要将 80k 行数据发送到前端。如果它只需要返回一些非聚合行，那么您确实需要分析您的索引。

I have added index for all combination

太多的索引和太少的索引一样对性能不利。