MySQL MyISAM/InnoDB 更新不是跨两个连接的原子更新（强制写入？）答案

【问题标题】：MySQL MyISAM/InnoDB updates are not atomic across two connections (force write?)MySQL MyISAM/InnoDB 更新不是跨两个连接的原子更新（强制写入？）
【发布时间】：2013-09-25 00:25:08
【问题描述】：

更新：我们尝试简单地将数据库转换为 InnoDB，但我们仍然遇到同样的问题。 autocommit 已开启。是否可能需要一些额外的声明来确保其他连接可以看到更改？

更新 2：我们设法通过将表设置为 InnoDB 将全局事务隔离级别设置为 SERIALIZABLE 来使事情正常进行，但这明显减慢了速度.此外，并非所有人都完全相信这已经解决了问题，因为减速可能只是让竞争条件有足够的时间以正确的顺序执行。无论如何，我们正在继续调查。

我在 MySQL 中遇到了一个问题，即从一个连接进行的写入不能立即从另一个连接看到（这恰好是 SOLR 更新查询）。

是这样的：

用户在网络应用中进行了更改。
我们注意到当前的修订号 r1。
MySQL 表 (MyISAM) 是使用更改和 下一个 修订版 r2 编写的。 [此时代码中的更改应该已写入数据库，如果我们从同一连接再次查询它，我们将看到它。]
我们通过 http 向 Solr 发出信号以使用修订版 r1 更新自身。
Solr（来自不同的连接）查询 MySQL 的更改 > r1，但没有获取刚刚在步骤 3 中编写的更改。

这是预期/正常的行为吗？我在文档中找不到任何表明更新不是跨连接原子的内容。请记住，在第二个连接发出信号进行自我更新时，更改应该已经写入数据库。

如果这是正常行为，则必须有某种方法强制 MySQL 将其连接写入/刷新回磁盘以强制进行正常的原子操作并保证其他连接会看到更改。但是，我再一次找不到关于 MyISAM 表的任何提及。

我还应该补充一点，如果我在第 3 步和第 4 步之间明确地放置一个短暂的延迟（1-2 秒），事情就会正常工作。

以下是我们正在运行的 MySQL 版本：

mysql-server-5.1.66-2.el6_3.x86_64
php-mysql-5.3.3-14.el6_3.x86_64
mysql-libs-5.1.66-2.el6_3.x86_64
mysql-5.1.66-2.el6_3.x86_64

【问题讨论】：

MyISAM 表是垃圾，引擎很糟糕。如果可以，请使用 InnoDB，因为它是一个适当的符合 ACID 的事务性 MVCC 数据库引擎。它还将所有事务刷新到磁盘以确保它们已提交。
@tadman：“将事务刷新到磁盘”不是 ACID 中的 D(urability) 吗？
这是个好消息，伙计们，我们也在考虑改用 InnoDB。
正确。我认为您将从该引擎中获得更多可预测的行为。您可以使用 ALTER TABLE ... ENGINE=InnoDB 转换您的表格，这对于少量数据需要很短的时间。

标签： php mysql solr myisam

【解决方案1】：

MyISAM 不会刷新到磁盘，它会写入文件系统缓冲区，操作系统最终会负责写入磁盘。

但是无论如何，另一个查询，甚至是另一个会话中的一个查询，应该能够立即读取该 MyISAM 数据，即使它是从文件系统缓冲区中读取的。该部分对 mysqld 进程应该是透明的。

MyISAM 中也没有事务隔离，所以不存在未提交的更改。无论事务隔离模式如何，任何会话都应该能够读取针对 MyISAM 表的任何已完成更改。

因此，如果您使用 MyISAM 表，那么您描述的步骤（步骤 5 没有看到对 r2 的更改）永远不会发生。因此，我猜您误解了操作的顺序，并且您实际上是在尝试读取尚未实际进行的更改。

无论如何，这没有实际意义，因为您确实应该使用 InnoDB。那么事务隔离确实很重要。您可能需要 READ-COMMITTED 的事务隔离，它不会像 SERIALIZABLE 那样阻塞并发，但它确实允许事务查看任何数据的最新版本。也就是说，如果您提交更改，并且 Solr 正在使用 READ-COMMITTED，那么 Solr 应该会立即看到更改。

【讨论】：