MySQL事务超时多长时间

Question

MySQL事务可以持续多长时间才会超时？我问，因为我打算为我的电子商务项目编写支付流程（PHP / MySQL伪代码）：

START TRANSACTION;

SELECT...WHERE id IN (1,2,3) AND available = 1 FOR UPDATE; //lock rows where "available" is true

//Do payment processing...

//add to database, commit or rollback based on payment results

我想不出另一种方法来锁定所购买的产品（所以如果两个用户同时购买它，并且只剩下一个用户，一个用户将无法购买），处理付款如果产品可用，并根据付款结果创建记录......

Answer 1

该技术还会阻止那些只想查看其他人购买的产品的用户。我会特别警惕任何依赖数据库行锁定来强制执行库存管理的技术。

相反，为什么不简单地记录当前在活动“交易”中绑定的项目数量（这里意味着更广泛的商业意义，而不是技术数据库意义）。如果您有current_inventory字段，请添加on_hold或being_paid_for或not_really_available_because_they_are_being_used_elsewhere字段，您可以使用有关当前付款的信息进行更新。

更好的是，为什么不使用购买/付款日志来汇总几个不同用户当前“暂停”或“处理中”的项目。

这是您经常在Ticketmaster等网站上看到的一般方法，声明“您有X分钟完成此页面，或者我们会将这些机票重新投放市场。”他们正在记录用户当前正在尝试购买的项目，这些记录甚至可以在PHP页面请求中保留。

Answer 2

超时取决于服务器设置 - 包括mysql和用于与mysql交互的语言的设置。查看服务器的设置文件。

我不认为你在做什么会导致超时，但如果你担心你可能想重新考虑检查的位置，以便它实际上不会跨查询锁定表。您可以使用内置于数据层的存储过程，而不是依赖于两个单独的调用。或者，可能是条件插入还是条件更新？

总而言之，正如另一个人所说，我不喜欢锁定整个表行的想法，你可能希望能够在实际的“购买”步骤之外为其他目的选择，因为它可能导致在应用程序的其他地方出现问题或瓶颈。

Answer 3

如果你不得不问数据库连接超时之前有多长时间，那么你的交易需要花费太长的订单。

长期交易是一个大问题，也是导致性能不佳，不可重复的错误甚至整个应用程序死锁的常见原因。当然，在Web应用程序中，您需要严格的快速事务，以确保快速释放所有表和行级锁。

我发现即使是几百毫秒也会变得很麻烦。

然后存在可能同时发生的多个请求共享事务的问题。

如果您需要“模拟”长时间运行的事务，请将其剪切成可以快速执行的较小部分，并保留日志，以便您可以通过撤消事务来使用日志回滚。

现在，如果支付服务在98％的情况下在不到2秒的时间内完成，并且您没有数百个并发请求正在进行，那么它可能就好了。