Perl 模块：MySQL 与 DBI
我们的许多自动化流程都使用 perl，并且需要访问我们的 MySQL 数据库。我不愿意承认这一点，但直到最近我们还没有真正对我们的大多数流程进行太多的基准测试。我们的一位开发人员设置了一个测试，通过以下伪代码来比较“使用 MySQL”与“使用 DBI”的性能：
for ($i = 1; $i <= 1000; $i++) {
pull and store all records in a 4,000 record table
}
结果： MySQL - 57s、56s、57s DBI - 43s、42s、43s
出于某种原因，我很惊讶地看到 DBI 的表现如此之好；考虑到我对这两个模块知之甚少。我意识到运行的基准测试可能存在一些问题，并且每个人的设置/结果都会非常不同，但我很好奇其他人是否通过使用 DBI 与 MySQL 模块体验到了任何形式的性能提升。
A lot of our automated processes use perl and need to access our MySQL DBs. I hate to admit it, but up until recently we haven't really done much benchmarking with the majority of our processes. One of our devs setup a test to compare the performance of "use MySQL" vs "use DBI" with the following pseudocode:
for ($i = 1; $i <= 1000; $i++) {
pull and store all records in a 4,000 record table
}
Results:
MySQL - 57s, 56s, 57s
DBI - 43s, 42s, 43s
For some reason I was surprised to see DBI performing so much better; considering how little I know about either of the modules. I realize that there are likely several things wrong with the benchmark that was run and that everyone's setups/results are going to very but I was curious whether others have experienced any sort of performance gain by using DBI vs the MySQL module.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我找到了他指的 MySQL 模块，它曾经是DBD::mysql dist.引用它
所以仿真层是导致性能损失的原因。另外，
MySQL.pm在 DBD::mysql 的 4.x 行中被删除，它最后一次出现是在 2006 年。I found the MySQL module he's referring to, it was part of the DBD::mysql dist. To quote it
So the emulation layer is the reason for your performace loss. Also that the
MySQL.pmwas removed in 4.x line of DBD::mysql, it last appeared in 2006.