使用DBIx :: Connector而不是简单地将mysql_auto_reconnect设置为1有什么好处？

Question

在处理持久的MySQL连接时，一个问题是它们在一定的超时（通常是28800秒）后被丢弃。 DBIx :: Connector似乎完成了自动重新连接到已断开连接的工作，但它为每个SQL语句添加了更多Perl代码，这可能会让人讨厌。例如，而不是：

    $dbh->do('DROP DATABASE stackoverflow');

人们不得不说：

    $conn->run(
        fixup => sub {
            my $dbh = shift;
            $dbh->do('DROP DATABASE stackoverflow');
        }
    );

假设一个人不需要交易。为什么要使用DBIx :: Connector而不是传递$ dbh - > {mysql_auto_reconnect} = 1，哪个也运行良好？

Answer 1

1. DBIx::Connector的既定目标是提供DBI的connect_cached()的分叉和线程安全实现。所以你几乎要问苹果/橘子的问题。 但是，如果连接丢失，当它在ping或fixup Connection Modes中运行时，DBIx :: Connector也会重新连接。请注意，默认值为no_ping模式，显然不会尝试重新连接。
2. DBIx :: Connector可以与任何数据库后端一起使用，而不仅仅是MySQL。

所有人都说...如果你使用的是MySQL，并且不关心DBIx :: Connector的其他优点（例如，因为你从不分叉或使用线程），那么mysql_auto_reconnect可能是你的最佳选择。