Question

我有一个或多或少良好的工作查询（关于结果）但是需要大约45秒来处理。这对于在GUI中呈现数据来说肯定太长了所以我的要求是找到一个更快/更有效的查询（大约几毫秒的东西会很好）我的数据表有 ~~3000~~ ~2,619,395个条目，并且仍在增长。

架构：

num | station | fetchDate             | exportValue | error
1   | PS1     | 2010-10-01 07:05:17   | 300         | 0
2   | PS2     | 2010-10-01 07:05:19   | 297         | 0
923 | PS1     | 2011-11-13 14:45:47   | 82771       | 0

解释

exportValue始终递增
exportValue表示实际绝对值
在我的情况下有10个站点
每隔约15分钟就会有10个新条目写入表格
错误只是适当工作站的指标

工作查询：

select
    YEAR(fetchDate), station, Max(exportValue)-MIN(exportValue)
from
    registros
where
    exportValue > 0 and error = 0 
group
    by station, YEAR(fetchDate)
order 
    by YEAR(fetchDate), station

输出：

Year | station | Max-Min
2008 | PS1     | 24012
2008 | PS2     | 23709
2009 | PS1     | 28102
2009 | PS2     | 25098

我的想法：

在“2008-01-01和2008-01-02之间”等语句之间写入几个查询以获取MIN（exportValue）以及在2008-12-30和2008-12-31之间获取MAX（ exportValue） - 问题：很多查询以及在指定时间范围内没有数据的问题（不保证会有数据）
仅使用MIN（fetchDate）命令将结果集限制为我的10个站点 - 问题：处理查询也需要很长时间

附加信息：
我在JAVA应用程序中使用该查询。这意味着，如有必要，可以对结果集进行一些后处理。（JPA 2.0）

非常感谢任何帮助/方法/想法。提前谢谢。

Answer 1

添加合适的索引会有所帮助。 2个复合指数将显着加快速度：

ALTER TABLE tbl_name ADD INDEX (error, exportValue);
ALTER TABLE tbl_name ADD INDEX (station, fetchDate);

Answer 2

在3000条记录上运行的查询应该非常快。

建议：

你在这张桌子上设置了PK吗？ station，fetchDate？
添加索引;您应该尝试使用索引进行试验，并在他的回答中建议使用rich.okelly
取决于对索引的实验，尝试将查询分解为多个语句 - 在一个存储过程中;这样您就不会在从客户端发送到mysql的多个查询之间的网络流量中浪费时间
您提到您尝试使用单独的查询，并且在特定月份没有数据时出现问题;它是业务应用程序中的常规情况，您应该在“主查询”（存储过程或应用程序代码）中处理它
猜fetchDate是记录插入时的当前日期和时间;考虑将前几个月的数据保存在带有字段的汇总表中：年，月，站，最大（exportValue），min（exportValue） - 这意味着您应该在每个月末在汇总表中插入汇总记录;删除，保留或移动详细记录到单独的表是您的选择

由于您的桌子快速增长（每15分钟一次），您应该考虑最后一个建议。可能没有必要在一个地方保留详细的历史记录。存档数据是应该作为维护的一部分完成的过程。

mysql查询 - 优化大型表的现有MAX-MIN查询

2 个答案: