MySQL事务超时多长时间

Question

MySQL事务超时多久？我这么问是因为我打算为我的电子商务项目某处的这种（PHP/MySQL的伪代码）的线CODE的支付流程：

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

超时取决于服务器设置 - 既是mysql的语言，也是您用来与mysql进行交互的语言的时间。查看服务器的设置文件。

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

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

Answer 2

该技术还会阻止那些仅仅想要的用户看到他人正在购买的产品。对于任何依靠数据库行锁定来强制执行库存管理的技术，我都会格外谨慎。相反，为什么不简单记录当前活跃的“交易”（这里意味着更广泛的商业意义，而不是技术数据库意义）中绑定的项目数量。如果您有current_inventory字段，请添加一个on_hold或being_paid_for或not_really_available_because_they_are_being_used_elsewhere字段，您可以使用有关当前付款的信息进行更新。

更好的是，为什么不使用购买/支付日志来对多个不同用户的当前“搁置”或“处理中”项目进行求和。

这是您经常在Ticketmaster这样的网站上看到的一般方法，它声明：“您有X分钟才能完成此页面，否则我们会将这些票据放回市场。”他们正在记录用户当前正试图购买的项目，这些记录甚至可以在PHP页面请求中持续存在。

Answer 3

如果您不得不问问在数据库连接超时之前它有多长时间，那么您的事务处理的时间量级过长。

长时间打开的事务是一个很大的问题，经常会导致性能不佳，无法修复的错误，甚至导致整个应用程序死锁。当然，在Web应用程序中，您需要紧密的快速事务来确保快速释放所有表和行级锁。

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

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

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

现在，如果支付服务在不到2秒的时间内完成了98％的案例，并且您没有数百个并发请求，那可能就没事了。