缓存一个非常缓慢的查询结果集

我有一个约1300万行的表。每行代表特定日期特定时间内特定项目的某种类型的度量。缓存一个非常缓慢的查询结果集

我有一个查询，根据测量类型找到这些值的总和或平均值。这很慢，就像几分钟。

我们有一些利用这个查询结果的报告页面，但是页面加载需要多分钟是不可接受的。到目前为止，我的解决方案是将查询的结果缓存在我称之为汇总表的内容中。

问题是刷新汇总表的夜间运行脚本运行时间太长。我甚至没有试图一次刷新整个汇总表，但它仍然需要很长时间。（通过“太长”我的意思是提出错误，刷新工作没有完成。）

我有一种预感，我面临的挑战是以错误的方式进行事情的结果，解决方案可能不会调整一些东西来削减1％的查询运行时间，而是以完全不同的方式处理问题。

任何建议，将不胜感激。如果我不是以很好的方式提出这个问题，我很抱歉;我不知道如何更好地制定它。乐于提供澄清或更多细节。

下面是查询的简化版本，需要永久运行。（即使这个简化版需要相当长的时间。）

select date(calc_dt), 
     project_id, 
     calculation_type_cd, 
     sum(result) 
    from calc_calculation_results 
group by date(calc_dt), 
     project_id, 
     calculation_type_cd

每晚的工作基本上是一个SELECT INTO负责这种查询的结果，并将它们放入我的汇总表。 result列是我们为报告目的感兴趣的值。

来源

2016-12-14 Jason Swett

你使用任何指标？什么错误正在提出？你是说这个查询在某个时候死了吗？ –

真的Jason拥有一个14k的代表，你真的应该知道这个问题模糊不清，因为这只是无法回答。 – RiggsFolly

@TimBiegeleisen我得到[这个错误]（http://stackoverflow.com/questions/5836623/getting-lock-wait-timeout-exceeded-try-restarting-transaction-even-though-im）我碰巧遇到问五年前的另一个问题。我桌子上的“SHOW INDEX FROM”确实揭示了许多索引，但我不知道如何分辨相关的内容。 –

汇总表 - 很好。重建它们 - 不好。相反，每晚增量增加它们。

使用摘要表，主表需要很少的索引，从而使其更加高效地加载。

摘要表具有适合查询的任何索引。

More discussion of Summary Tables

你的简化版可能成为

INSERT INTO Summary (date, project_id, type_cd, sum_result) 
    select CURDATE() - INTERVAL 1 DAY, 
      project_id, 
      calculation_type_cd, 
      sum(result) 
    from calc_calculation_results 
    WHERE calc_dt >= CURDATE() - INTERVAL 1 DAY 
     AND calc_dt < CURDATE() 
    group by project_id, 
      calculation_type_cd

它可能有

PRIMARY KEY(date, project_id, type_cd), 
INDEX(project_id, date), 
INDEX(type_cd, date)

来源

2016-12-15 04:27:47

缓存一个非常缓慢的查询结果集

回答

相关问题