php - MySQL 事务时序

Question

我有一些使用 PHP 和 MySQL 的经验，并且我了解事务，但使用它们的经验相当少。

我正在开发一个 Web 应用程序，用户将在其中对单个数据库进行/执行各种 CRUD 操作。 (是的，它是 InnoDB)。我很好奇交易的行为方式，我会给你一个相当简单的例子:

1.) 用户 1 开始一个事务，将我的数据库中的 John Smith 的名称更新为 Johnathon Smith。

2.) 用户 2 开始一项交易以读取 John Smith 的姓名紧接在用户 1 的交易开始之后，但在此之前已提交。

用户 2 会看到什么结果？ John 还是 Johnathon？

用户1在交易过程中，John Smith的记录是被锁定了，还是交易过程中可以读取？

此外，这两个交易的时间安排如何？用户 2 的交易是否坐在某个队列中等待用户 1 的交易完全完成？ MySQL 数据库如何对试图访问同一表/记录的多个事务进行分类？

另外，假设用户 1 的交易操作平均需要 500 毫秒才能完成，而用户 2 的交易操作平均需要 750 毫秒才能完成。用户 2 的响应时间有多长？ 1250 毫秒？

非常感谢任何指向相关文章或其他 SO 问题的链接!

Answer 1

它的默认工作方式是用户 2 看到 John Smith，直到用户 1 提交并且用户 2 开始新事务。 p>

换句话说，默认事务隔离称为可重复读取。也就是说，InnoDB 假设用户 2 希望看到用户 2 开始其当前事务时的数据库。即使其他人更新数据并提交他们的更新，用户 2 仍然希望看到原始数据，直到他明确刷新他的数据库“ View ”。

MySQL 解决这个问题的方法是保留更新行的两个版本。 Johnathon Smith 的“当前”版本有一个指向该行先前版本的内部指针。 InnoDB 将检查这些版本，确定用户 2 是否应该能够看到当前版本，如果不能，则按照指向先前版本的指针。这是逐行自动完成的。

用户 2 的交易根本没有理由等待，这就是“读者不会阻止写入者，反之亦然”的意思。这就是多版本并发控制 (MVCC) 功能的好处，它在许多 RDBMS 产品中都有类似的实现，例如 Oracle、PostgreSQL 和 Firebird。

一旦用户 1 提交了他的更改，并且没有仍在运行的事务需要查看该行的先前版本，InnoDB 就会有一个后台线程逐渐清理那些旧版本。

这很重要，例如对于想要运行多个查询并且希望所有小计匹配的报告应用程序。如果报告中的后一个查询看到了一个稍微更新的数据库 View ，它们可能会得到与前一个查询不同的结果。

您可以选择将事务隔离级别更改为 READ-COMMITTED，这样用户 2 将自动不断刷新他的数据库“ View ”，以查看更新后的名称 Johnathon Smith(原文如此)但是仅在用户 1 提交后。如果用户 1 尚未提交，则用户 2 无法看到更改。

您甚至可以将事务隔离级别更改为 READ-UNCOMMITTED，这样用户 2 甚至可以在用户 1 提交之前看到更新。但这很少是您想要做的——用户 1 可以回滚，因为 Johnathon 显然是 Jonathan 的拼写错误。

您可以尝试自己测试所有这些，方法是打开两个运行 mysql 客户端的 shell 窗口，并在它们之间来回跳转，看看更改如何从一个 session 到另一个 session 可见。

您将想要了解如何使用 SET TRANSACTION更改每个 session 的事务隔离级别的语句。

另见:

• MySQL/InnoDB and long-running queries
• InnoDB's row locking the same as MVCC Non-Blocking Reads?
• http://dev.mysql.com/doc/refman/5.6/en/innodb-transaction-model.html
• High Performance MySQL, 3rd edition