DBI的fetchall_hashref和fetchall_arrayref之间的性能差异是什么？

Question

我正在编写一些Perl脚本来操作两个PostgreSQL数据库中的大量数据(总共大约4200万行,但不会在一次命中中完成).

对于我的一些查询,使用它是合理的,fetchall_hashref因为我有合成键.但是,在其他情况下,我将使用三列数组作为唯一键.

这让我想知道fetchall_arrayref和之间的性能差异fetchall_hashref.我知道在这两种情况下,一切都进入内存,因此选择几GB数据可能不是一个好主意,但除此之外,在性能方面,文档中似乎没有什么指导.

我的谷歌搜索没有成功,所以如果有人能指出我的一些一般性能研究的方向,我将不胜感激.

(我知道我可以自己对此进行基准测试,但不幸的是,出于开发目的,我无法访问具有相同硬件和生产的机器,这就是为什么我正在寻找一般指导方针甚至是最佳实践).

Answer 1

fetch方法之间的大多数选择取决于您希望数据最终的格式以及您希望DBI为您做多少工作.

我的回忆是,使用fetchrow_arrayref进行迭代并使用bind_columns是读取返回数据的最快(最少DBI开销)方式.

Answer 2

第一个问题是你是否真的fetchall需要首先使用 a 。如果您不需要一次将所有 4200 万行存储在内存中，那么就不要一次将它们全部读入！ bind_columns正如fetchrow_arrayrefysth 已经指出的那样，通常是尽可能可行的方法。

假设fetchall确实需要，我的直觉是，这fetchall_arrayref会稍微快一些，因为数组是一种更简单的数据结构，不需要计算插入键的哈希值，但节省的时间与数据库读取时间相比是相形见绌的，所以它不太可能很重要。

不过，内存要求完全是另一回事。返回的结构fetchall_hashref是 的哈希值id => row，每一行都表示为 的哈希值field name => field value。如果您获得 4200 万行，这意味着您的字段名称列表在 4200 万组散列键中的每组中都会重复...这将需要比 . 返回的数组的数组的数组多得多的内存来存储fetchall_arrayref。（我想，除非 DBI 正在做一些魔术tie来优化fetchall_hashref结构。）