嵌套 sql 上的 Perl DBI 性能答案

【问题标题】：Perl DBI Performance on nested sql嵌套 sql 上的 Perl DBI 性能
【发布时间】：2011-08-17 04:14:02
【问题描述】：

我对 perl dbi 中嵌套形式的性能处理 sql 有疑问。

基本上，脚本正在做的是

连接到 DB1

连接到 DB2

从 DBI 获取数据

在一个while循环中，

使用来自 DB1 的数据并创建更新或插入语句

在 DB2 中执行 sql

与 DB2 不兼容

断开 DB1

现在的问题是，就性能而言，这是最佳做法还是以下方法是最佳选择。

从 DB1 获取日期

将数据写入暂存文件

从暂存文件中获取数据
  process the data to udpate in DB2. 

编辑：我在连接到 DB1 后添加了连接到 DB2。但这不是我要说明的重点。这更多是关于服务器正在从数据库服务器和存储数据的磁盘读取的 I/O 和系统调用的性能问题。

如果您查看第一种方法。

在循环中。脚本从 DB1 获取一行数据并等待返回的数据在 DB2 中得到处理。

如果有数千条记录，当您对服务器进行数千次系统调用以从磁盘读取数据时，对性能有何影响

【问题讨论】：

【解决方案1】：

我在 Perl 方面只有中等经验，但这项工作涉及 Perl 和数据库。据我了解，通常最好在循环之外连接到数据库——这样可以最大限度地减少重复连接、断开连接和重新连接的开销。

所以...

连接到 DB1

连接到 DB2

从 DB1 获取数据

在一个while循环中

使用 DB1 中的数据并创建更新或插入语句

在 DB2 中执行 sql

从 DB1 断开

与 DB2 断开连接

【讨论】：

【解决方案2】：

如果有数千条记录，当您对服务器进行数千次系统调用以从磁盘读取数据时，对性能有何影响

考虑到典型的小或平均记录大小，数千条记录并不多。您不知道数据是否实际上是从磁盘读取的，或者更确切地说是驻留在内存中的缓冲区中。所以你不能确定系统调用的数量。你为什么要打扰？

如果性能对您很重要，我建议您在典型的真实场景中测试这两种方法。

如果您正在处理锁定数据库和长时间运行的进程（无论出于何种原因），最好一次获取您需要的所有数据（暂存文件方法），这样您就不会持有锁在整个处理期间在源服务器和目标服务器上。

您的选择还可能取决于您对批量导入数据的工具或 API 的熟悉程度。例如，MSSQL 的bcp.exe 是用于导出和导入数据的便捷工具。大多数其他数据库都有类似的工具。

【讨论】：

【解决方案3】：

我建议并行执行，例如在您的脚本中使用pipe() 和fork()。否则大多数时候您将等待网络 IO。所以就像

(SELECT, serialize, print) | (read line, deserialize, INSERT_OR_UPDATE)

【讨论】：