问题:如何在应用层处理MySQL死锁情况?

当 MySQL/InnoDB 发生死锁情况时,它会返回这个熟悉的错误:

'尝试获取锁时发现死锁;尝试重新启动事务'

所以我所做的是记录进入事务的所有查询,以便在事务中的语句失败时可以简单地重新发出它们。简单的。

问题:当您的查询依赖于先前查询的结果时,这不会很好。

例如:

START TRANSACTION;
INSERT INTO some_table ...;
-- Application here gets ID of thing inserted: $id = $database->LastInsertedID()
INSERT INTO some_other_table (id,data) VALUES ($id,'foo');
COMMIT;

在这种情况下,我不能简单地重新发出最初创建的事务。第一条 SQL 语句获取的 ID 在事务失败后不再有效,而是被第二条语句使用。同时,许多对象已经填充了来自事务的数据,然后当事务回滚时这些对象就变得过时了。当然,应用程序代码本身不会随数据库“回滚”。

问题是:如何在应用程序代码中处理这些情况? (PHP)

我假设两件事。如果您认为我走在正确的轨道上,请告诉我:

1)由于数据库不能在所有情况下都逐字重新发出事务,所以我原来的解决方案不起作用,不应该使用。

2)做到这一点的唯一好方法是将任何和所有事务发布代码包装在它自己的 try/catch 块中,并尝试重新发布代码本身,而不仅仅是 SQL。

感谢您的输入。你摇滚。

解答

交易可能会失败。死锁是一种失败的情况,在可序列化级别上也可能有更多失败。事务隔离问题是一场噩梦。试图避免失败是我认为的坏方法。

我认为任何编写良好的事务代码都应该有效地为失败的事务做好准备。

正如您所见,记录查询并重放它们不是解决方案,因为当您重新启动事务时,数据库已经移动。如果这是一个有效的解决方案,SQL 引擎肯定会为您做到这一点。对我来说,规则是:

• 重做事务内部的所有读取(您在外部读取的任何数据都可能已被更改)

• 抛出之前尝试的所有内容,如果您在事务之外编写了内容(日志、LDAP、SGBD 之外的任何内容),它应该因为回滚而被取消

• 实际上重做一切:-)

这意味着重试循环。

所以你有你的 try/catch 块,里面有事务。您需要添加一个可能尝试 3 次的while循环,如果代码的提交部分成功,则离开 while 循环。如果在 3 次重试之后事务仍然失败,那么向用户启动一个异常——这样你就不会尝试无限重试循环,实际上你可能遇到了一个非常大的问题——。请注意,您应该以不同的方式处理 SQL 错误和锁定或可序列化异常。 3 是任意数字,您可以尝试更多次数。

这可能会给出类似的结果:

$retry=0;
$notdone=TRUE;
while( $notdone && $retry<3 ) {
  try {
    $transaction->begin();
    do_all_the_transaction_stuff();
    $transaction->commit();
    $notdone=FALSE;
  } catch( Exception $e ) {
    // here we could differentiate basic SQL errors and deadlock/serializable errors
    $transaction->rollback();
    undo_all_non_datatbase_stuff();
    $retry++;
  }
}
if( 3 == $retry ) {
  throw new Exception("Try later, sorry, too much guys other there, or it's not your day.");
}

这意味着所有的东西(读、写、功能的东西)都必须包含在$do_all_the_transaction_stuff();中。暗示事务管理代码在控制器中,即_high-level-application-functional-main code_,而不是拆分为几个_low-level-database-access-models对象_。