Question

我有这个查询，每个请求只运行一次。

SELECT SUM(numberColumn) AS total, groupColumn
FROM myTable
WHERE dateColumn < ? AND categoryColumn = ?
GROUP BY groupColumn
HAVING total > 0

myTable只有不到十几列，可以增长到500万行，但更有可能产生约200万行。查询中使用的所有列都是数字，dateColumn除外，dateColumn和categoryColumn上有索引。

如果数据库得到适当优化，是否有理由期望此查询在大多数现代服务器上在5秒内运行500万行？

我问的原因是我们没有5百万的数据，我们在未来几年内甚至不会达到2百万，如果查询不能在5秒内运行，那么很难知道问题所在。是因为查询不适合大型表，或者数据库没有优化，还是服务器不够强大？基本上，我想知道在大表上使用SUM()和GROUP BY是否合理。

感谢。

Answer 1

正如您在问题中的评论中提到的那样，最简单的验证方法是生成随机数据并测试查询执行时间。请注意，在dateColumn上使用聚簇索引可以显着改变执行时间，因为“＆lt;”条件仅检索连续磁盘数据的子集以计算总和。

如果您处于开发过程的开始阶段，我建议您不要专注于收集数据的表和索引的结构 - 而是将来期望从表中检索什么。我可以通过向网站管理员介绍Web使用统计信息来分享自己的经验。我从服务器请求了几个网页，每个网页都在一个更多的“类别”上。我的第一种方法是使用一些索引收集日志表中的每个请求，但是表的增长比我最初估计的要大得多。 :-)由于统计数据以常数组（每周，每月和每年）进行分析，因此我决定创建在预定义的周/月/年grop中聚合请求的附加表。每个请求都会增加相关列 - 列引用了我的“类别”。这破坏了一些规范化规则，但允许我在一眨眼间计算统计数据。

Answer 2

一个重要的问题是dateColumn＆lt; ？条件。我猜它是过滤过时的记录。表格中有多少条记录并不重要。重要的是这种情况会减少多少记录。

按日期进行积极过滤并结合按日期对表进行分区可以在可笑的大表上为您提供惊人的性能。

作为旁注，如果你不期望在未来的许多年里能够获得这么多数据，那就不要费心去解决它。到那时，您的业务需求可能会改变十几次，以及体系结构，数据库布局，设计和实现细节。提前规划很有意义，但有时你想尽快给出一个足够好的解决方案，并在下一个版本中处理未来的痛苦问题..

在mysql上执行数百万行的SUM（）和GROUP BY

2 个答案: