PDO fetch 语句之间是否存在性能差异?
就像默认值是 FETCH BOTH一样
/* Exercise PDOStatement::fetch styles */
print("PDO::FETCH_ASSOC: ");
print("Return next row as an array indexed by column name\n");
$result = $sth->fetch(PDO::FETCH_ASSOC);
print_r($result);
print("\n");
print("PDO::FETCH_BOTH: ");
print("Return next row as an array indexed by both column name and number\n");
$result = $sth->fetch(PDO::FETCH_BOTH);
print_r($result);
print("\n");
print("PDO::FETCH_LAZY: ");
print("Return next row as an anonymous object with column names as properties\n");
$result = $sth->fetch(PDO::FETCH_LAZY);
print_r($result);
print("\n");
print("PDO::FETCH_OBJ: ");
print("Return next row as an anonymous object with column names as properties\n");
$result = $sth->fetch(PDO::FETCH_OBJ);
print $result->NAME;
print("\n");
,我想知道当我要获取大量数据时 FETCH ASSOC 是否更快;或者它们是相同的?
谢谢
like in
/* Exercise PDOStatement::fetch styles */
print("PDO::FETCH_ASSOC: ");
print("Return next row as an array indexed by column name\n");
$result = $sth->fetch(PDO::FETCH_ASSOC);
print_r($result);
print("\n");
print("PDO::FETCH_BOTH: ");
print("Return next row as an array indexed by both column name and number\n");
$result = $sth->fetch(PDO::FETCH_BOTH);
print_r($result);
print("\n");
print("PDO::FETCH_LAZY: ");
print("Return next row as an anonymous object with column names as properties\n");
$result = $sth->fetch(PDO::FETCH_LAZY);
print_r($result);
print("\n");
print("PDO::FETCH_OBJ: ");
print("Return next row as an anonymous object with column names as properties\n");
$result = $sth->fetch(PDO::FETCH_OBJ);
print $result->NAME;
print("\n");
Well the default are FETCH BOTH, I am wondering if FETCH ASSOC is faster when I'm going to fetch a lot of data; or they are the same?
Thanks
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
我想知道这个问题的答案,所以我写了一个快速的基准脚本。
我建议您在自己的服务器上运行此基准测试,但是,这是我的设置中的典型结果,对于单行结果:
对于大型数据集,这些结果是典型的:
请参阅 git hub 上的评论,获取所有行确实会更改测试。
I wanted to know the answer to this question, so I wrote a quick benchmark script.
I suggest you run this benchmark on your own server, however, this is a typical result on my setup, for single row results:
For large data sets, these results are typical:
See the comments on git hub, fetching all the rows does change the test.
当您不需要时,不要获取大量数据。就这样。
一旦您需要它 - 这些方法之间的微观差异将是您最不关心的。
Do not fetch a lot of data, when you don't need it. that's all.
Once you need it - microscopic difference between these methods would be your least concern.
另一个答案中发布的基准脚本正在计算准备()和执行()的时间,因此我编写了一个脚本仅用于测试获取时间。我有MySQL数据库,大约有100000行真实数据。 LongRow 包含 TEXT 列(每行大约 4kB 数据)。 ShortRow 是(每行 30 个字节)。 FETCH_INTO 使用具有所有列属性的预定义类。 PHP 版本 5.4。 MySQL 5.5.35。这里缺少一件事:一些运行的平均值。
这也是一个代码:
The benchmark script posted in another answer is counting prepare() and execute() to the time so I write a script for testing only fetch time. I have MySQL database, with about 100000 rows of real data. LongRow contains TEXT column (about 4kB of data per row). ShortRow is (30 bytes per row). FETCH_INTO uses predefined class with all column properties. PHP version 5.4. MySQL 5.5.35. One thing is missing here: average of some runs.
Here is a code too:
ASSOC、BOTH 和 OBJ 通常是相同的,只是它们返回不同的结构。那里没有性能差异。
LAZY 执行某种延迟加载。 PDO::FETCH_LAZY 在访问对象变量名称时创建它们。这意味着只有在访问属性时才会受到性能损失,而在调用 fetch() 时则不会。如果您仅使用返回数据的一部分,这非常有用。
ASSOC, BOTH and OBJ are generally the same, except that they return a different structure. No performance differences there.
LAZY does some sort of lazy loading. PDO::FETCH_LAZY creates the object variable names as they are accessed. This means that you get the performance penalty only when you access the properties, not when calling fetch(). This is useful if you use only a part of the returned data.
最后一个答案很愚蠢(“不获取......”):如果您必须转换大表或接口数据库表的数据怎么办?
我更改了上面的基准测试代码,因为它没有正确测试恕我直言(每个循环一次提取是不够的;-)),我将其替换为每个提取类型 10000 条记录 x 100 次循环。
我添加了 Fetch_class 这是我对自己的问题。
我添加了一个真实的类来确定后一个测试是正确的。
结果(已排序):
惰性值不完整,因为没有访问权限。
但“两者”实际上都有影响
Last answer is silly ("do no fetch...."): what if you have to transform data for a big table, or interface dbs tables?
I changed the benchmarking code above, because it was not testing corretcly IMHO (one single fetch per loop is not enough ;-) ), I replaced it by 10000 records x 100 loops per fetch type.
I added Fetch_class which was the question I had for myself.
I added a real class to be certain the latter test was correct.
results (sorted):
Lazy value is incomplete, since there is no access.
but "Both" actually HAS impact