我有一个视图,大约需要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分钟。
对所有行运行上述查询永远不会完成!将该查询插入空表中永远不会完成。
我有效地处理了两个问题。
我正在使用amazon redshift
提前谢谢
答案 0 :(得分:0)
对于您的第一个问题,数据库是数据的结构化存储,以便人们可以轻松访问准确且一致的数据。写入数据库总是比读取数据库慢。 INSERT总是比SELECT长。有时甚至更长。
这取决于您的系统为什么插入1000行需要5分钟。使用现代数据库,通常不需要这么长时间。但是,如果您使用amazon redshift中的低级数据库,并且/或者如果您的视图表具有很多具有复杂性的列,则很容易花费很多时间。
对于你的第二个问题,没有适当的背景,很难说。但是,如果您的SELECT查询只花了1秒钟,我的猜测是数据库可以很快找出您想要写入的数据集。我的猜测是数据库的写入速度正在发生变化。也许您正在使用写入性能最低速度较低的低层服务。
答案 1 :(得分:0)
您必须了解数据库设计的内容才能理解为什么这么慢。您需要查看正在运行的硬件上的外键,是否存在隐式转换,是否存在触发器。
您需要查看插入时索引的字段。您需要查看选择查询是否需要基础表上的更多索引才能使插件运行得更快。
当然,所有这些案例陈述都会让它们自己变慢。它们可以用更快但更复杂的东西替换,看起来像一系列UNION(或者最好是UNION ALL)语句吗?
它也可能是网络管道问题。有时,直接在数据库上运行的东西比从其他位置运行更好。
接下来,你几乎不想一次性插入600,000,000。批量生成通常更快,并且在进入下一批之前提交批次。这是因为否则事务日志会填满,这可能是缓慢的一部分。
有很多关于性能调优的书籍,您需要为所选数据库阅读它们。这种事情从来都不简单。也不能在这样的地方妥善解决。在你甚至可以开始解决这个问题之前,这是你个人需要深入了解的事情。这就是为什么数据库专家对于任何复杂的大型数据库系统都是必需的。如果您在数据库的一个视图中有这么多记录,并且没有数据库专家来帮助您,那么您需要雇用一个,因为您没有必要的10,000小时的专业知识和经验才能有效地执行此操作。