Catalyst 类慢响应

我有一个DBIx：：类查询，需要花费很长时间才能完成

下面的所有SQL都是由DBIx:：Class生成的

第一个场景（DBIx简单选择）：

SELECT me.pf_id, me.origin_id, me.event_time, me.proto_id FROM pf me ORDER BY event_time DESC LIMIT 10;

SELECT me.pf_id, me.origin_id, me.event_time, me.proto_id FROM pf me WHERE ( proto_id = 7 ) ORDER BY event_time DESC LIMIT 10;

SELECT me.pf_id, me.origin_id, me.event_time, me.proto_id FROM pf me WHERE ( proto_id = 7 ) ORDER BY event_time DESC LIMIT 10;

DBIx查询时间：0.390221s（正常）

第二个场景（DBIx使用where简单选择）：

SELECT me.pf_id, me.origin_id, me.event_time, me.proto_id FROM pf me ORDER BY event_time DESC LIMIT 10;

SELECT me.pf_id, me.origin_id, me.event_time, me.proto_id FROM pf me WHERE ( proto_id = 7 ) ORDER BY event_time DESC LIMIT 10;

SELECT me.pf_id, me.origin_id, me.event_time, me.proto_id FROM pf me WHERE ( proto_id = 7 ) ORDER BY event_time DESC LIMIT 10;

DBIx查询时间：29.27025s！！：(

第三种场景（使用pgadmin3运行上述查询）：

SELECT me.pf_id, me.origin_id, me.event_time, me.proto_id FROM pf me ORDER BY event_time DESC LIMIT 10;

SELECT me.pf_id, me.origin_id, me.event_time, me.proto_id FROM pf me WHERE ( proto_id = 7 ) ORDER BY event_time DESC LIMIT 10;

SELECT me.pf_id, me.origin_id, me.event_time, me.proto_id FROM pf me WHERE ( proto_id = 7 ) ORDER BY event_time DESC LIMIT 10;

Pgadmin查询时间：25ms（确定）

同样的查询使用pgdamin非常快

一些信息：

• 催化剂5.90091
• DBIx:：Class 0.082820（最新版本）
• 博士后9.1
• 我使用Catalyst内部服务器在localhost上进行了所有测试
• 我对任何其他表/列组合都没有问题，它与proto_id有关
• DBIx:：Class:：Schema:：Loader自动生成的数据库架构
• 原型id定义：
  “原始id”， {data_type=>“smallint”，is_foreign_key=>1，is_nullable=>0}

有人知道为什么DBIx要花这么长时间运行这个简单的查询吗

编辑1：列正在使用索引（btree）

编辑2：这是一个分区表，我正在检查所有子表是否都有所有索引，但仍然没有解释为什么在DBIx:：Class上相同的查询速度较慢

编辑3：我做了一个简单的DBIx:：类，得到了相同的结果，只是为了确保问题不在于Catalyst框架

编辑4：使用tcpdump，我注意到postgres的响应时间太长，仍在尝试

---

编辑5：似乎速度很快，我几乎确信这是一个DBIx:：类问题。

经过一些测试，我发现了问题：

由于某种原因，当我使用DBI进行查询时（正如DBIx:：Class所做的），它变得非常慢

SELECT me.pf_id, me.origin_id, me.event_time, me.proto_id FROM pf me WHERE ( proto_id = ? ) ORDER BY event_time DESC LIMIT ?;

my $sth = $dbh->prepare($sql);
$sth->bind_param(1, 80, { TYPE => SQL_INTEGER });
$sth->bind_param(2, 10, { TYPE => SQL_INTEGER });
$sth->execute();

所以在搜索CPAN一段时间后，我注意到我的已经过时了（我的不好）。我从CPAN下载了源代码，编译后问题就消失了。一定是旧版本的一些bug

---

TL；DR：如果您在DBI或DBIx:：Class方面遇到问题，请确保您的DBI数据库驱动程序已更新。

proto_id上是否有索引？您可以从mysql命令行工具中检查第二个场景需要多长时间。这可能会将问题隔离到数据库而不是软件层。您已将其标记为perl问题，但您没有不要显示任何perl代码。关于索引的问题很好。计时是否可重复？通常，数据库将以大致相同的方式运行查询，而不管执行查询的客户端是谁，因此我希望查看执行计时的代码。其中可能包含其他延迟。是的，有一个使用btree的索引