提高 30 亿行表的 SQL 查询执行时间

Question

我有一个超过 2 亿行的 mysql 表。我每天还写 100 万行。该表包含一些大列，例如varchar(255)（用于保存长网址）

为了在此表上执行分析，我创建了 5 个特定索引，这确实加快了执行时间。（对于某些查询，从 25 分钟以上到 2 分钟）。

问题仍然存在，2 分钟对于一个查询来说已经是很多时间了。我想运行多个查询以进行分析和报告。

此外，该表每天都在快速增长，我非常确定索引已尽可能优化。

这是集群可以解决我的问题的地方吗？也就是说，如此大小的表仍然在单个 sql 节点上运行，这是否不寻常？

或者是否仍然可以在如此大的表中以毫秒为单位运行查询？

我的一个示例查询是：

SELECT name, url, SUM(visits), AVG(price), AVG(loc) FROM mytable
    WHERE sname IN ('white') AND usage IN ('three') AND date BETWEEN '2001-01-01' AND '2003-03-10'
    GROUP BY name, url ORDER BY SUM(visits);

我对集群和 HPC 很陌生，对于我应该在这里做什么的任何建议，我们都很感激。

Answer 1

您的问题中未包含很多信息，这使得提供完整的答案相当困难。但是，仅使用您共享的内容：

\n

这是集群可以解决我的问题的地方吗？

\n

不见得。集群提供了很多优点，但它似乎不是您想要做的事情的正确解决方案。随着每天添加一百万行，您的主系统需要针对写入进行优化。在谈论报告时，您可能可以使用针对读取进行优化的系统。

\n

这种大小的表仍然在单个 SQL 节点上运行，这很不寻常吗？

\n

这里的异常程度在很大程度上取决于业务的需求（和期望）。我希望在某个地方有一个热备用或复制实例，可以在主服务器发生故障时随时投入使用。每秒插入 11.5 条记录，没有太多停机空间。

\n

这么大的表还可以在毫秒内运行查询吗？

\n

如果有足够的硬件，我不明白为什么不这样做。然而，很少有人能够获得整个数据中心的全部计算能力。

\n\n

一般来说，当我不得不处理这样的情况时，我会尽量让事情变得简单，并就人们试图从系统收集的报告类型提出具体问题。如果存在共同的模式，那么扁平化的历史表格就为每个人节省了大量的时间。毕竟，当您可以以一种使长期报告更快且同样准确的方式汇总数据时，为什么要每周查询 2003 年的相同数据一千次呢？

\n

然而，我解决此类问题的主要方法之一 \xe2\x80\x94 通常适用于每天从遍布全国和整个太平洋的地震仪和气象站收集数百万条记录的大学 \xe2\x80\x94是“作弊”并拥有一个每天仅更新其源表一次或两次的复制实例。这使得系统可以针对具有大量索引的读取进行优化，从而使主服务器针对具有较少索引（如果有的话）的写入进行优化。

\n

对于常见报告，会按每小时/每晚的时间表查找数据中的模式并将其放入汇总表中，从而可以快速生成常见报告。还可以针对复制实例运行临时或更具体的查询，而不必担心影响主系统的性能。只要生成的报告不需要是“实时”的，这种方法通常就有效，并且可以在合理的预算内完成，这是管理类型倾向于赞赏的。

\n

请注意，不要将这个答案视为任何超出思考范围的事情。正如一开始提到的，有很多信息没有被提及。，例如报告的目标受众、数据库用于哪些其他任务、查询历史数据的频率与历史数据的频率等。 .当前数据等。这只是当我被要求解决类似的问题时基于过去经验的一个选择。

\n