0

哪个更好？

1)一个游标，循环30000条记录，一一更新

2)创建一个包含30000条更新命令的脚本

谢谢

4

3 回答 3

2

两者应该花费大约相同的时间，主要取决于 CURSOR 的声明方式。

原因？您有 30,000 个单独的更新，这通常是主要因素

请注意，由于批量大小和编译时间，一批中的 30,000 个单独的更新可能会失败......

SQL 是一种基于集合的语言，您很可能只需执行一次 UPDATE 即可一次更新所有行。如果你不能，那是因为2个原因

  1. 您需要“每行”逻辑：这通常可以通过 CASE 表达式、UDF 等来实现
  2. 你不懂集合和 SQL

有了更多信息（SQL 和逻辑），我们可以为您提供更多帮助...

于 2013-01-16T07:56:00.370 回答
0

有一个非常简单的方法来判断：做它并测量时间。

除此之外，当你只有 10 行时，拥有 30000 行并没有多大意义。

出于数据迁移或维护以外的原因以这种方式进行更新听起来也不明智，在这些情况下，性能不是问题 - 但维护和易读性始终是问题。

于 2013-01-16T07:44:24.543 回答
0

你知道，这取决于上下文。

不过，它有助于学习。以 SQL 为例。您处于低水平，看不到这里可能的真正优化。SQL 不仅仅是更新、插入和简单的选择语句。

1)一个游标，循环30000条记录，一一更新

线性逐步处理。无法并行化，因为 SQL 本身没有可供用户使用的线程机制；优化是一项一项的——即查询优化器一次只查看一条语句。

2)创建一个包含30000条更新命令的脚本

假设脚本是外部的，它可以拆分工作并在多个连接上并发运行，即运行多个并行。

但还有更多：

  • 制作一个计算新值的脚本。
  • 使用 buld copy API 将它们批量导入临时表
  • 发出一条更新语句，将临时表中的更新值带到最后一个。

也许有一个脚本可以为多重更新发出合并语句？如果您对 SQL api 的了解不仅仅是“更新、打开游标、简单选择”，那么这里有很多变化。

我这样做 - 尽管有更多数据（50.000 批，有时同时 4-6 批）。问题是 sql 批量复制有一些开销。但我以这种方式每秒管理 75.000 次插入。

很大程度上取决于业务问题和逻辑的复杂性——如果是简单的更新，那么问题是：计算还是外部驱动？多个值乘以 2 = 计算，更新地址 = 数据驱动（即您需要来自某个地方的新数据）。

于 2013-01-16T07:59:01.633 回答