mysql和oracle有区别吗

上周我和一位同事讨论过这个问题。

MySQL和Oracle其实有很大不同。

发送交易的方法。
MySQL默认会自动调度，并在执行SQL语句后生效。
Oracle 的情况并非如此。
默认情况下需要手动提交，您必须自己键入命令或单击按钮确认。

分页查询也完全不同。
MySQL 可以使用 LIMIT x, y 来做到这一点，例如 SELECT FROM table LIMIT 1 0, 2 0。
Oracle 的问题要多得多。
必须使用ROWNUM嵌套查询，例如SELECT FROM (SELECT a., ROWNUM FROM table a WHERE ROWNUM <= 3 0) WHERE rn > 1 0
事务隔离级别也不同。
默认情况下，MySQL 是已提交读。
您可以看到提交的其他更改，但无法防止不可重复读取。
Oracle默认使用REPEATABLE READ，它使用UNDO表空间创建多个版本，以确保事务中显示的结果始终相同。
最高级别的 SERIALIZABLE 支持两者。

数据持久化和恢复。
难怪MySQL重启后会丢失数据，没有写入硬盘的缓存也消失了。
甲骨文要好得多。
将提交的操作写入在线重做日志，支持介质损坏恢复，还可以恢复到某个时间点。
数据更加安全。

竞争控制也很差。
MySQL主要依赖于表锁，而InnoDB支持行锁但依赖于索引。
Oracle 的默认行锁定仅锁定那些数据行。
与指数无关，竞争能力强。

备份完全相同。
MySQL备份首先必须锁定数据以保证一致性，但这会影响业务。
Oracle采用MVCC，备份时不需要阻塞，不影响业务。

复制和灾难恢复能力更差。
设置MySQL复制很简单，但如果主数据库损坏，数据可能会丢失，需要手动更换备份数据库。
Oracle有DataGuard，可以自动切换到多节点容灾，但是设置比较复杂。

性能诊断工具也不同。
MySQL 主要查看慢查询日志。
Oracle具有AWR报告、ADDM自动诊断、SQLTrace和深度优化。

权限和安全模型也很差。
MySQL权限与用户主机绑定，很容易被IP欺骗。
Oracle 使用角色授权系统来精细地控制审计。

主要定位不同。
MySQL是轻量级的、开源的，适合中小型用户。
Oracle的企业级商用、高可用性、高安全性产品还提供全面的服务。

算了。

MySQL中如何实现分布式事务_两阶段提交及替代方案？

哎呀，说到MySQL的分布式事务，有很多值得说的。
我们需要从两阶段提交（2 PC）开始。
这是一件古老的古董，但它仍然有它的地位。

我们先来说说2 PC。
它就像一个总司令，召集所有参与交易的节点，要么一起发送，要么回滚。
这就像一支军队。
总司令一声令下，大家一起行动。
分为两个阶段，准备阶段和提交阶段。

在准备阶段，总指挥（协调员）向每个士兵（参与者）发送消息，询问他们是否准备好。
士兵们首先要完成任务，写日记，然后告诉指挥官他们是否准备好了。
如果一切准备就绪，我们就进入提交阶段。

投降阶段，如果所有士兵都说准备好了，总司令就会下令，大家一起发出。
如果一名士兵说他没有准备好，总司令必须发布撤回命令以撤销刚刚所做的事情。

这听起来很简单，但实际上存在很多问题。
比如说，统帅出了事，全军都得等他。
这称为单点故障。
再比如，士兵要等待总司令的命令，资源要被锁定，效率很低。
另外，当网络分区时，可能有的士兵已经被送进来，而另一些则没有，这可能会导致数据不一致。

还有其他选择吗？当然有，例如TCC（尝试-确认-取消）。

TCC就像一名消防员。
它首先尝试灭火（尝试）。
如果火被扑灭（确认），则无需担心。
如果未能扑灭大火（取消），则必须重新开始。

再比如消息队列+本地事务表。
这就像一个快递员。
当您下订单时，我会先为您注册。
然后我会找快递通知对方，对方收到通知后进行处理。

还有一个Saga模式，就像一个脚本。
一个大的交易被分成几个小脚本。
每个脚本对应一个本地事务。
如果中间出了问题，就按照脚本逆向操作，将之前的事情全部撤消即可。

选择哪个计划取决于您的需求。
如果一致性要求较高，2 PC可能是一个不错的选择。
如果你对并发和性能要求较高，TCC或者消息队列+本地事务表可能更适合你。
如果业务流程复杂，对性能要求较高，Saga模型可能更适合。

总之，分布式事务没有一刀切的解决方案，必须根据具体情况来决定。

mysql如何使用rollback回滚事务

等等，我昨天在调试数据库的时候遇到了一个奇怪的事情。
系统突然卡住了。
我检查了日志，发现两个线程同时更新同一个表，一个提交，另一个回滚。
结果，他们就互相锁定了。
当时我就想，如果这个不及时回滚的话，数据肯定会乱掉。
MySQL的事务机制确实相当有趣。
想一想，如果转账操作只扣除了A的钱，而B方根本不加钱，那么如何处理这种数据不一致的问题呢？ 您是否想发送两条短信提醒用户“您转了1 000，但对方没有收到”？ 这个业务逻辑太复杂了。

一文说尽MySQL事务及ACID特性的实现原理

这就是陷阱。
尽管InnoDB很普遍，但像MyISAM和Memory这样的引擎不支持事务。

实用提醒：检查您的业务需求，选择支持事务的存储引擎。