我有一些 InnoDB 表和一个启动事务的脚本。在此事务中，一个表的不同行得到更新，其他行将被插入到另一个表中，并执行许多选择。这必须可靠地发生，所以我使用默认事务和 REPEATABLE READ 作为隔离级别。此交易可能需要一些时间。
现在，当其他脚本(网页请求)同时执行时，它们会在数据库中进行一些选择。不幸的是，这些选择会等到事务结束，因为它们是从相同的表中读取的。选择的数据可以是交易的更新数据，也可以是其他数据。
这种阻塞是我想避免的。我想立即将网页显示给用户，不能等待交易(一两秒是可以接受的，但交易有时会更长)。
那么我该如何选择呢？我想那时的数据可能并不总是准确的。但这比让用户等待 20 秒要好。
我应该
- 在交易中选择“FOR UPDATE”或“LOCK IN SHARE MODE”？
- 使用另一个隔离级别？
- 将阅读选择也放在事务中？
- 做一些不同的事情？
我认为这是一个非常普遍的要求，但我还没有找到一个简单的答案。
注意:下一步是确保并发写入事务的安全。但现在我只想确保至少并行读取不会在事务期间被阻塞。
最佳答案
好吧，这不是一个真正的答案，但我想我应该说出我发现了什么:
我猜这与 MySQL 操作没有任何关系。它实际上是在挂起 PHP 请求。也就是说，当第一个 PHP 调用启动了长期持续的事务时，对其他页面的进一步 PHP 调用已挂起。而他们挂起的原因是 session 被第一个请求锁定了! session_start()没有工作了。就在第一个请求完成(或超时)时，其他请求将再次运行。
由于具有长事务的 PHP 调用不需要向 session 中写入任何内容，因此我只需使用 session_write_close() 关闭 session 即可。在这次通话中。现在，进一步的请求不再挂起。
This是给我的提示。
结论:数据库选择没有被阻塞。
关于php - 如果正在进行交易，如何避免阻塞选择？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/37524534/