在高度并发的Rails系统中处理瞬态数据库错误的“最佳实践”是什么？

在研究死锁问题时，我发现了以下post：

https://rails.lighthouseapp.com/projects/8994/tickets/6596

它的要点如下：

1. MySQL文档说：

   死锁是事务数据库中的一个典型问题，但它们并不危险，除非它们如此频繁以至于根本无法运行某些事务。 通常， 您必须编写应用程序，以便在由于死锁而回滚时，它们始终准备重新发出事务 。

2. 因此，调试瞬态死锁是一种反模式，因为MySQL认为它们是可行且不可避免的。

3. 因此，Rails应该为我们提供一种方法，因为它：

   假设存在“最佳”的做事方式，并且它旨在鼓励这种方式

4. 但是Rails并没有为我们提供一种方式，所以我们使用的是一种hacky DIY的东西。

所以如果所有这些都是真的，那么Rails解决方案在哪里？

---

注意：此项目处于非活动状态，但似乎很简单，可以作为解决方案。 为什么Rails没有这样的东西？ https://github.com/qertoip/transaction_retry

Answer 1

对我来说，修复是一个更好的索引。

有问题的更新是在带有连接的查询中，现有的索引不足以让MySQL有效地加入和搜索。

即使在具有不合理并发负载的测试中，添加适当的索引也完全消除了死锁问题。