将视图插入表格 - 视图不需要很长时间才能运行 - 插入需要很长时间

Posted 2023-02-26

【中文标题】将视图插入表格 - 视图不需要很长时间才能运行 - 插入需要很长时间

【英文标题】：Inserting view into table - view doesn't take long to run - Insert takes forever

【发布时间】：2018-02-08 17:31:37

【问题描述】：

我有一个大约需要 1 秒才能返回 1000 行的视图。 但是，当我尝试将其插入到表中时，需要很长时间（即使只有 1000 行）。

FULL 视图本身返回大约 600,000,000 行。由于我机器的限制，我一次只能显示 1000 个。当我将视图限制为 1000 行时，运行需要 1 秒。当我尝试插入这 1000 行时，需要几分钟！ 我还尝试插入所有 6 亿行，但这永远不会完成 - 2 小时超时。

   SELECT *
   FROM vw_view1
   LIMIT 1000

以上运行需要 1 秒

   insert into table1

    SELECT *
    FROM vw_view1
    LIMIT 1000
     ;

以上需要5分钟！

是否有理由简单地查询视图需要第二个，而插入需要 5 分钟？请记住，这仅适用于 1000 行！我需要实际插入 600,000,000！

这是我的观点的查询

出于保密目的，我已排除字段名和表名

  SELECT id, sheet, "timestamp", "timestamp"::date AS date,
  "date_part"('year'::text, "timestamp") AS year, "date_part"('month'::text, "timestamp") AS month, user_id, 
    CASE
          WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        ELSE 'Free'::text
    END AS column1, 
    CASE
         WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        ELSE 'Homel'::text
    END AS column2, 
    CASE
       WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        ELSE 'include'
    END AS column3, 
    CASE
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        WHEN XX like %...%.... THEN ...ZZ
        ELSE 'ignore'

    END AS column4
    FROM views;

因此，对 1000 行运行上述查询需要 1 秒。将该查询插入空表需要 5 分钟。

为所有行运行上述查询永远不会完成！将该查询插入空表永远不会完成。

我实际上有两个问题。

为什么将简单的选择插入空表需要这么长时间 如何优化上述查询

我正在使用亚马逊红移

提前谢谢你

【问题讨论】：

您在问为什么插入/选择 1000 行比插入/选择 600,000,000 行要快？

可能有很多东西。我想到了重写索引和外键检查。

空表上有触发器吗？可以显示sql插入代码吗？

【参考方案1】：

对于您的第一个问题，数据库是数据的结构化存储，以便人们可以轻松访问准确且一致的数据。写入数据库总是比读取数据库慢。 INSERT 总是比 SELECT 花费更长的时间。有时数量级更长。

这取决于您的系统，为什么插入 1000 行需要 5 分钟。使用现代数据库，通常不需要这么长时间。但是，如果您使用来自 amazon redshift 的低层数据库，和/或如果您的视图表有很多复杂的列，则很容易花费大量时间。

对于您的第二个问题，没有适当的上下文，很难说。但是，如果您的 SELECT 查询只需要 1 秒，我猜数据库可以相当快地找出您想要写入的数据集。我的猜测是数据库的写入速度有问题。也许您使用的是低层服务，其写入性能的最大速度较低。

【参考方案2】：

您必须了解您的数据库设计发生了什么，才能理解为什么这很慢。您需要查看外键、正在运行的硬件、是否发生隐式转换、是否有触发器。

您需要在插入时查看它正在索引的字段。您需要查看是否需要基础表上的更多索引，以便选择查询以使插入运行得更快。

当然，所有这些 case 语句本身都会使其变慢。可以用看起来更快但更复杂的东西代替它们吗，比如一系列 UNION（或者最好是 UNION ALL）语句？

也可能是网络管道问题。有时事情直接在数据库上运行比从其他位置运行更好。

接下来，您几乎不想一次性插入 600,000,000 个。分批执行并在进入下一个之前提交批次通常更快。这是因为否则事务日志会填满，这可能是缓慢的一部分。

关于性能调优的书籍非常多，您需要针对您选择的数据库阅读它们。这种事情从来都不是简单的。在这样的地方也不能适当地解决它。这是您个人需要深入了解的内容，然后才能开始解决此问题。这就是为什么任何复杂的大型数据库系统都需要数据库专家。如果您在数据库中的一个视图中有这么多记录，并且没有数据库专家来帮助您，那么您需要雇用一位，因为您没有必要的 10,000 小时的专业知识和经验来有效地做到这一点。