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

Question

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

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

它的要点如下：

1. MySQL文档说：

     

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

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

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

     

   假设有最好的＆＃34;做事的方式，它旨在鼓励这种方式

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

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

---

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

Answer 1

对我来说，修复是一个更好的指标。

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

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