游标中嵌套游标
我有一个游标,
CURSOR B_CUR IS select DISTINCT big_id from TEMP_TABLE;
它会返回多个值。早期它被用作
FOR b_id IN B_CUR LOOP
select s.col1, s.col2 INTO var1, var2 from sometable s where s.col3 = b_id.col1;
END LOOP;
早期确定内部选择查询将始终返回 1 行。现在这个查询可以返回多行。我怎样才能改变这个逻辑?
我正在考虑创建一个嵌套游标,它将获取记录类型的数组(我将声明),但我不知道嵌套游标在这里如何工作。
我主要关心的是效率。因为每次执行它都会处理数百万条记录。你们能建议这里最好的方法是什么吗?
I have a cursor which is
CURSOR B_CUR IS select DISTINCT big_id from TEMP_TABLE;
This would return multiple values. Earlier it was being used as
FOR b_id IN B_CUR LOOP
select s.col1, s.col2 INTO var1, var2 from sometable s where s.col3 = b_id.col1;
END LOOP;
Earlier it was certain that the inner select query would always return 1 row. Now this query can return multiple rows. How can I change this logic?
I was thinking to create a nested cursor which will fetch into an array of record type (which i will declare) but I have no idea how nested cursor would work here.
My main concern is efficiency. Since it would be working on millions of records per execution. Could you guys suggest what would be the best approach here?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
通常,您只需连接两个表即可。
既然你关心效率,那么
TEMP_TABLE
真的是临时表吗?如果是这样,为什么? Oracle 实际上需要使用临时表的情况极其罕见,因此我怀疑您可能首先做了一些低效的操作来填充临时表。FOR
循环来处理TEMP_TABLE
中的数据?逐行处理是 PL/SQL 中执行任何操作最慢的方法,因此如果您担心效率,通常会避免使用它。从性能的角度来看,您希望最大化 SQL,这样您就不需要执行一系列单行 INSERT 或 UPDATE 操作的循环,而是执行单个操作修改整组行的INSERT
或UPDATE
。如果您确实需要分块处理数据,那么 PL/SQL 集合和批量处理就可以发挥作用,但这不会像直接 SQL 那样高效。TEMP_TABLE
的查询中包含DISTINCT
?您真的希望存在没有错误的重复big_id
值吗?大多数时候,人们错误地使用 DISTINCT 来掩盖数据错误连接的问题,或者强制 Oracle 进行昂贵的排序,以防将来创建不正确的数据。约束将是保护自己的更合适的方式。Normally, you would just join the two tables.
Since you are concerned about efficiency, however
TEMP_TABLE
really a temporary table? If so, why? It is exceedingly rare that Oracle actually needs to use temporary tables so that leads me to suspect that you're probably doing something inefficient to populate the temporary table in the first place.FOR
loop to process the data fromTEMP_TABLE
? Row-by-row processing is the slowest way to do anything in PL/SQL so it would generally be avoided if you're concerned about efficiency. From a performance standpoint, you want to maximize SQL so that rather than doing a loop that did a series of single-rowINSERT
orUPDATE
operations, you'd do a singleINSERT
orUPDATE
that modified an entire set of rows. If you really need to process data in chunks, that's where PL/SQL collections and bulk processing would come in to play but that will not be as efficient as straight SQL.DISTINCT
in your query againstTEMP_TABLE
? Do you really expect that there will be duplicatebig_id
values that are not erroneous? Most of the time, people useDISTINCT
incorrectly either to cover up problems where data has been joined incorrectly or where you're forcing Oracle to do an expensive sort just in case incorrect data gets created in the future when a constraint would be the more appropriate way to protect yourself.