0

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

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

myTable有不到十几个列，可以增长到 500 万行，但在生产中更可能是 200 万行。查询中使用的所有列都是数字，除了，并且在和dateColumn上有索引。dateColumncategoryColumn

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

我问的原因是我们没有 500 万条数据，我们甚至不会在未来几年内达到 200 万条，如果查询没有在 5 秒内运行，那么很难知道在哪里问题出在哪里。会不会是查询不适合大表，或者数据库没有优化，或者服务器不够强大？基本上，我想知道使用SUM()and GROUP BYover a large table 是否合理。

谢谢。

4

2 回答 2

2

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

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

于 2012-07-26T17:16:58.867 回答
1

一个重要的问题是 dateColumn < ? 健康）状况。我猜它正在过滤过时的记录。表中有多少记录并不重要。重要的是这种情况减少了多少记录。

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

附带说明一下，如果您不希望在未来的许多年中获得这么多数据，请不要费心解决它。届时，您的业务需求可能会发生十几次变化，包括架构、数据库布局、设计和实现细节。提前计划很好，但有时您希望尽快提供足够好的解决方案并在下一个版本中处理未来的痛苦问题。

于 2012-07-26T17:07:11.377 回答