事务及四大特性 原子性（Atomicity）：指事务包含的所有操作要么全部成功，要么全部失败回滚。 一致性（Consistency）：事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。 隔离性（Isolation）：当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间

四个隔离级别如下： 读未提交（read uncommitted），指一个事务还没提交时，它做的变更就能被其他事务看到； 读提交（read committed），指一个事务提交之后，它做的变更才能被其他事务看到； 可重复读（repeatable read），指一个事务执行过程中看到的数据，一直跟这个事务启动时看到的数据是一致的，MySQL InnoDB 引擎的默认隔离级别； 串行化（*s

最近在学习数据库事务相关的知识，事务最重要的就是隔离级别，不同的隔离级别对于我们查询出来的结果是不一样的，也对应着不同的业务场景，而innodb的隔离级别是依靠mvcc来实现的，好不容易理解了mvcc，但是在学到锁的时候，大脑又宕机了，mvcc的功能都这么强了，还要这么多复杂的锁干嘛呢？ 带着问题去思考后，我的一点薄见：锁和mvcc的结合，可以更好的帮助事务隔离级别去解决并发问题下的一系列问题，且

在并发访问下，MySQL事务中的死锁问题是一种常见的情况。当多个事务同时请求和持有相互依赖的资源时，可能会出现死锁现象，导致事务无法继续执行，严重影响系统的性能和可用性。 死锁问题的原因分析 竞争资源：当多个事务同时请求和持有相同的资源，如行级锁，表级锁等，可能会导致死锁问题的发生。 事务执行顺序：当多个事务按不同的顺序请求和释放资源时，可能会产生死锁的可能性，这是因为事务的执行顺序无法保证一致性

背景 继上次的if else优化也有段时间了，最近小猫又又又着道了，接手的那个项目又遇到了坑爹的地方，经常性的报死锁异常，经常性的主从延迟......通过报错信息按图索骥，发现代码是这样的。 这是一段商品发布的逻辑，我们可以看到参数校验、查询、最终的insert以及update全部揉在一个事务中。遇到批量发布商品的时候就经常出现问题了，数据库主从延迟是肯定少不了的。 开启优化 其实像上述小猫遇到的

分布式事务是处理跨多个服务的原子操作的关键概念，而选择适合应用场景的框架对于确保事务一致性至关重要。以下是几个常见的分布式事务框架，并讨论它们的使用和实践。 1. XA协议 XA协议是一种经典的分布式事务协议，通过两阶段提交（2PC）来实现事务的原子性。它适用于要求强一致性的场景，但也因为其阻塞和单点故障的问题而受到一些批评。在使用XA协议时，需要确保数据库支持XA事务，并配置协调者和参与者。 实

爱可生开源社区 2024 全新技术专栏《MySQL 核心模块揭秘》第一期。 作者：操盛春，爱可生技术专家，公众号『一树一溪』作者，专注于研究 MySQL 和 OceanBase 源码。 爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。 本文基于 MySQL 8.0.32 源码，存储引擎为 InnoDB。 1. 事务池和管理器 作为 MySQL 中支持事务的默认存储引擎，

本文主要介绍了Spring事务传播性的相关知识。 Spring中定义了7种事务传播性： PROPAGATION_REQUIRED  PROPAGATION_SUPPORTS PROPAGATION_MANDATORY PROPAGATION_REQUIRES_NEW PROPAGATION_NOT_SUPPORTED PROPAGATION_NEVER PROPAGATION_NESTED 在Sp

一、案例描述 最近遇到这么一个案例（5.7版本），大概的截图如下： 当然这里是测试出来的，线上当时也是一个lock table read的语句和一大批insert into的语句被堵塞，当然要恢复很简单，我们可以通过2种方式，来查杀堵塞源头，如下： table 级别的MDL LOCK，除非手动发送lock table，那么其持续时间通常为事务级别，而innodb_trx中记录了全部的事务（只读和读

最强大的事务类型之一称为两阶段提交，当第一个事务的提交取决于第二个事务的完成时，它是摘要。特别是当您必须同时更新多个实体时，例如确认订单和立即更新库存时，它非常有用。 但是，例如，当您使用微服务时，事情变得更加复杂。每个服务都是一个独立的系统，拥有自己的数据库，您不再可以利用本地两阶段提交的简单性来维护整个系统的一致性。 当你失去这种能力时，RDBMS成为一个非常糟糕的存储选择，因为你可以完成相同

在微服务架构下，我们最容易遇到的一个问题就是分布式事务处理问题，当你微服务模块拆分越细，那么遇到分布式事务处理的场景就越多。即使是同一个微服务模块，对应一个业务数据库，但是你某个业务逻辑的实现是调用两个Service接口服务来完成的，同样也是分布式事务问题。 因此有必要对分布式事务整体解决思路进行下总结。 分布式事务概述 图片 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理

大家好，我是飘渺。今天继续DDD&微服务专栏。 在之前的文章 基于DDD的订单创建 流程中，我们留下了一个问题：在createOrder()方法中，我将调用远程接口获取购物车详情、远程库存校验、订单保存放在一个事务中，显然这并不是一个正确的做法，因为它会导致长事务，今天就让我们来解决这个问题。 图片 为什么会产生长事务 首先，让我们来分析一下产生长事务的原因。 在Spring中，@Transact

4、Binlog是如何写入的 由于MySQL的SQL和引擎层的双日志体系，Binlog写入需要解决多个引擎之间事务执行的一致性问题。此外，由于从日志产生到落盘是数据库写入的关键路径，所以写入的效率也是需要关注的。下面我就从这两个方面来介绍Binlog的写入过程。 4.1、分布式事务模型——XA XA源于Distributed Transaction Processing: The XA Speci

GTID标识了Binlog事务的全局唯一性，保证事务在集群的每个实例上有且只执行了一次。开启Binlog和GTID后，MySQL会为每个事务绑定一个GTID，该事务执行成功后，对应的GTID会被记录在Binlog中。因此MySQL可以通过GTID的状态来判断状态机状态，在搭建复制时，根据GTID判断上下游复制节点的事务执行状态，上游就可以将下游没有的事务同步到下游。 开启GTID需要设置enfor

定义 意向锁（Intention Locks）是 MySQL InnoDB 引擎中的一种锁机制（表级锁），用于协调事务间的加锁操作，以避免冲突和死锁的发生。 意向锁的作用 例如，事务 A 加锁了 Users 表中的一行数据（行锁），而事务 B 要对整个 Users 表进行加锁（表锁），那么这个时候，如果没有意向锁，那事务 B 就会加锁成功了。 而事务 B 如果加锁成功的话，那么它是可以对表中的任意

最近受废话文学的影响，所以有了今天的这个标题，希望大家能喜欢。大家不喜欢也没关系，反正我喜欢。 鲁迅先生曾经说过“我家门前有两棵树，一棵是枣树，另一棵还是枣树。”，由此可见，这老爷子算是把废话文学给玩明白了。 希望大家也能，听君一席话，如听一席话。 PS：这里没意向书什么事啊，标题中有，纯粹是为了好玩。它们不能说没什么关系，那是一点关系都没有啊。 为了避免这个问题，所以 MySQL 引入了意向锁，

在使用数据库的过程中，事务通常是我们一个很熟悉的概念。 事务的主要目标是确保一组数据库操作全部成功或全部失败。 在MySQL中，事务支持是在存储引擎级别实现的。 需要注意的是，MySQL 是一个支持多种存储引擎的系统，但并非所有引擎都提供事务支持。例如，MySQL原生的MyISAM存储引擎不支持事务，这也是InnoDB取代MyISAM的重要原因之一。 在这篇文章中，将以InnoDB为例，深入研究M

MVCC（Multi-Version Concurrency Control）是一种并发控制机制，用于解决数据库并发访问中，数据一致性问题。它通过在读写操作期间保存多个数据版本，以提供并发事务间的隔离性，从而避免了传统的锁机制所带来的资源争用和阻塞问题。 所谓的一致性问题，就是在并发事务执行时，应该看到那些数据和不应该看到那些数据。 在 MVCC 机制中，每个事务的读操作都能看到事务开始之前的一致

MySQL作为一款开源关系型数据库，如今绝对是占据关系型数据库的主导地位，不仅是面试中的常客，也是日常工作中最主要接触的数据库。因此，无论是背面试八股，还是工作使用，都是一定要深度掌握的一个知识点。今天就用一篇文章讲清楚MySQL的所有问题 着急的小伙伴可直接跳到最后MySQL常见面试题总结 一、事务 定义：一组操作要么全部成功，要么全部失败，目的是为了保证数据最终的一致性 在MySQL中，提供了

事务消息是RocketMQ的一个非常特色的高级特性，它的基础诉求是通过RocketMQ的事务机制，来保证上下游的数据⼀致性。 我们在单机版本下面只需要在业务方法上加上对应的事务就可以达到效果，但是分布式的场景下，多个系统之间的协调配合，你无法知道到底是那个先执行那个后执行，当然在微服务里面存在Seate框架来保证事务，但是这事务的保证始终是心头大患，只能用一句话形容鱼和熊掌不可兼得。 而Rocke