【问题标题】:Parallelism in stored procedure in mysql?mysql中存储过程的并行性?
【发布时间】:2015-06-25 15:17:47
【问题描述】:

我有一个存储过程来每天插入几条记录。每天执行相同的逻辑,但以顺序方式执行。所以为了提高性能,我在考虑引入并行性。那么有没有办法或者有人可以指出一些例子,我可以在存储过程中并行运行一些逻辑。

编辑: 我在存储过程中使用的查询是:

INSERT INTO tmp (time_interval, cnt, dat, txn_id) SELECT DATE_FORMAT(d.timeslice, '%H:%i') as time_interval
     , COUNT(m.id) as cnt
     , date(d.timeslice) as dat
     , "test" as txn_id
  FROM ( SELECT min_date + INTERVAL n*60 MINUTE AS timeslice
           FROM ( SELECT DATE('2015-05-04') AS min_date
                       , DATE('2015-05-05') AS max_date) AS m
         CROSS
           JOIN numbers
          WHERE min_date + INTERVAL n*60 MINUTE < max_date
       ) AS d
LEFT OUTER
  JOIN mytable AS m
    ON m.timestamp BETWEEN d.timeslice
                        AND d.timeslice + INTERVAL 60 MINUTE
GROUP
    BY d.timeslice;

此查询每天按小时对记录进行分组并插入到 tmp 表中。所以我想每天并行运行这个查询,而不是按顺序运行。

谢谢。

【问题讨论】:

  • 你能树立榜样吗?
  • 我已对问题进行了编辑以使其更加清晰。

标签: mysql database performance stored-procedures parallel-processing


【解决方案1】:

d 是代表一天 24 小时的一组 DATETIME 吗?我的直觉说它可以简化一堆。可以通过添加WHERE n BETWEEN 0 AND 23 来加速。也许:

SELECT '2015-05-04' + INTERVAL n*60 MINUTE AS timeslice
    FROM numbers
    WHERE n BETWEEN 0 AND 23

mytable 中有什么内容?特别是,“旧”数据是静态的还是变化的?如果它是不变的,为什么要反复重新计算呢?仅计算最后一小时,将其存储到永久(不是 tmp)表中。不需要并行。

如果数据发生变化,最好避免

ON m.timestamp BETWEEN d.timeslice
                   AND d.timeslice + INTERVAL 60 MINUTE

因为(我认为)它不会很好地优化。让我们看看EXPLAIN SELECT...

在这种情况下,使用存储过程来计算开始和结束时间并构造(想想CONCAT)带有常量的 ON 子句。

回到你的问题... MySQL 本身无法获得并行性。您可以编写单独的脚本来进行并行处理,每个脚本都有自己的参数和连接。

【讨论】:

  • 您的建议非常好,但只是没有得到如何替换“d.timeslice + INTERVAL 60 MINUTE”部分。
  • 进行我建议的其他更改,然后我们可以重新处理该建议。同时,在问题中添加对目标的描述;我无法推断出意图。
  • 我更改了整个查询,它现在按预期工作。感谢您提出处理查询的建议。
  • 这就是我想听到的。 :)
猜你喜欢
  • 2017-12-06
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-06-15
  • 1970-01-01
  • 2018-03-24
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多