Atomic是如何给出多个连接的Mysql事务？

Question

我检查了相关问题，答案是有点＆＃34;是的，非常原子＆＃34;。

但我更具体，因为那些问题不是那么具体，所以答案是：

1. 的MySQL / INNODB
2. ＆＃34;同一＆＃34;时间
3. 交易可能写相同的表（甚至更多，相同     查询）。
4. 只有一个数据库
5. 根本不会有锁定表
6. 。没有嵌套交易
7. 没有memcache或任何其他类似的系统，一切都很简单 可能的。
8. 我相信我们正在使用＆＃34;可序列化的isoloation，而不是低级＆＃34;

在这种情况下，我们是否通过Mysql引擎保证数据完整性将被保留，或者转向特定情况：

• 那些＆＃34;同时＆＃34;着作将排队？

• 事实上，回滚将按照规定运作。

• 读数＆＃34;同时＆＃34;会找到状态的一致性 那些着作？

我的简单问题是，如果＆＃34;提交＆＃34;和＆＃34;回滚＆＃34;不同连接的内部转换是原子的，或者只是弄得一团糟： - ）

感谢。

Answer 1

“提交”将结束交易。

事务隔离级别确实是否确定

• 在事务上下文中执行的所有语句都基于事务开始时的一致时间点快照（REPEATABLE READ和SERIALIZABLE），或者是否

• 事务中的每个语句都会看到其他事务（Oracle COMMITTED）提交的更改，或者

• 每个语句都会看到其他尚未提交的事务所做的更改SQL Server脏读（READ UNCOMMITTED）

回答你的问题：

当可以获得锁定时，将应用“同时写作”。如果没有其他会话持有不兼容的锁，则获取锁，并且可以应用更改。

回滚将按预期工作，也就是说，以ROLLBACK语句结束的事务将还原所应用的任何更改，锁定的行将返回到它们在事务开始时所处的状态，并且锁定将是释放。 （这还包括触发器应用的任何DML更改。）请注意，这仅适用于InnoDB。应用于MyISAM表的任何更改都将像Oracle样式的自治事务一样提交。

“同时读取”将分别来自一致的快照（具有REPEATABLE READ或SERIALIZABLE事务隔离级别。）

注意“提交”和“回滚”不会发生在“内部交易”中，它们会结束交易，它们标记交易的结束。交易开始时的一致快照消失了;下一个事务将获得自己的一致快照。这些操作最好被描述为“原子”，但它们本身并不会造成混乱。

这是InnoDB锁定机制，可以防止冲突的变化。如果两个同时会话试图对同一行进行更改（一个会话覆盖另一个会话所做的更改），则至少有一个事务将等待获取另一个事务所持有的锁。当第一个事务释放锁时，第二个事务可以获得锁，并继续进行更改;可以自由覆盖其他会话刚刚进行的更改。

事情是否真的变得混乱真的取决于交易的设计，以及什么是合法的。