mysql事务

1.事务的并发控制可能产生哪些问题 不同事务之间可能会互相影响，比如一个事务修改另一个事务也改了，但是另一个事务的修改把这个事务的修改给覆盖掉了，这就是所说的事务并发控制问题。 如果不对事务进行并发控制，可能会产生四种异常情况 幻读(phantom read) ：一个事务第二次查询出现第一次没有的结果，说明别的事务已经插入一些数据。注意这是在同一个事务里面的查询 非重复读(nonrepeatable read) ：一个事务重复读两次得到不同结果，说明读取操作结果是不可重复的。 脏读(dirty read): 一个事务读取到另一个事务没有提交的修改，就是当另一个事务它会没有提交修改一个事务就读取到了修改。 丢失修改(lost update) ：并发写入造成其中一些修改丢失。 2.四种事务隔离级别 为了解决并发控制可能产生的异常问题，数据库定义了四种事务的隔离级别 读未提交(read uncommitted) ：别的事务可以读取到未提交改变 读已提交(read committed) ：只能读取已经提交的数据 可重复度(repeatable read) ：同一个事务先后查询结果一样，Mysql InnoDB默认实现可重复读级别。 串行化(Serializable) ：事务完全串行化的执行，隔离级别最高，执行效率最低。 相当于把数据库在一个事务执行的时候完全锁住，等它执行完才能执行下一个。

前言 事务，是描述一组操作的抽象，比如对数据库的一组操作，要么全部成功，要么全部失败。事务具有4个特性：Atomicity（原子性），Consistency（一致性），Isolation（隔离性），Durability（持久性）。在实际开发中，我们对事务应用最多就是在数据库操作这一环，特别是Spring对数据库事务进行了封装管理。Spring对事务的支持，确实很强大，但是从本质上来讲：事务是否生效取决数据库底层是否支持（比如MySQL的MyISAM引擎就不支持事务，Spring能奈何！），同时一个事务的多个操作需要在同一个Connection上。事务也往往是在业务逻辑层来控制。本篇博客将通过手写一个Demo来分析Spring事务底层到底是如何帮助我们轻松完成事务管理的！ 透彻理解Spring事务设计思想之手写实现 先来看一眼工程结构： ConnectionHolder 在Spring中，有时候我们是不是要配置多个数据源DataSource？很显然，Spring需要通过DataSource来得到操作数据库的管道Connection，这有点类似于JNDI查找。 这里通过ConnectionHolder类来完成这个过程，需要思考的是在多线程下，这显然是存在问题的。为避免多线程问题，难道我们采用线程安全的Map，比如ConcurrentHashMap，其实我们真正的目的是什么

索引的概念 数据库中的索引与书籍中的目录类似 在一本书中，无须阅读整本书，利用目录就可以快速查找所需信息 书中的目录是一个词语列表，其中注明了包含各个词的页码 数据库索引 在数据库中，索引数据库程序无须对整个表进行扫描，就可以在其中找到所需数据 数据库中的索引是某个表中一列或者若干列值的集合，以及物理标识这些值的数据页的逻辑指针清单 索引的作用 设置了合适的索引之后，数据库利用各种快速的定位技术，能够大大加快查询速率； 特别是当表很大时，或者查询涉及到多个表时，使用索引可使查询加快成千倍； 可以降低数据库的IO成本，并且索引还可以降低数据库的排序成本； 通过创建唯一性索引保证数据表数据的唯一性； 可以加快表与表之间的连接； 在使用分组和排序时，可大大减少分组和排序时间； 索引的分类 普通索引 这是最基本的索引类型，而且它没有唯一性之类的限制 唯一性索引 这种索引和前面的"普通索引"基本相同，但有一个区别：索引列的所有值都只能出现一次，即必须唯一 主键 主键是一种唯一性索引，但它必须制定为"PRIMARY KEY" 全文索引 全文索引的类型是FULLTEXT，可以在VARCHAR或者TEXT类型的列上创建 单列索引与多列索引 索引可以是单列上创建的索引，也可以是在多列上创建的索引 创建索引的原则依据 表的主键，外键必须有索引； 数据量超过300行的表应该有索引；

1.1 逻辑架构 第一层：客户端通过连接服务，将要执行的sql指令传输过来 第二层：服务器解析并优化sql，生成最终的执行计划并执行 第三层：存储引擎，负责数据的储存和提取 1.2 锁 数据库通过锁机制来解决并发场景- 共享锁（读锁） 和 排他锁（写锁） 。 读锁是不阻塞的 ，多个客户端可以在同一时刻读取同一个资源。 写锁是排他的，并且会阻塞其他的读锁和写锁 。简单提下乐观锁和悲观锁。 乐观锁 ，通常用于数据竞争不激烈的场景， 多读少写 ， 通过版本号和时间戳实现。 悲观锁 ，通常用于 数据竞争激烈的场景 ，每次操作都会锁定数据。 要锁定数据需要一定的锁策略来配合。 表锁 ， 锁定整张表，开销最小，但是会加剧锁竞争 。 行锁 ， 锁定行级别，开销最大，但是可以最大程度的支持并发 。 但是MySql的存储引擎的真实实现不是简单的行级锁，一般都是实现了多版本并发控制（MVCC）。MVCC是行级锁的变种，多数情况下避免了加锁操作，开销更低。MVCC是通过保存数据的某个时间点快照实现的。 1.3 事务 事务保证一组原子性的操作，要么全部成功，要么全部失败。一旦失败，回滚之前的所有操作。MySql采用自动提交，如果不是显式的开启一个事务，则每个查询都作为一个事务。 未提交读 （Read UnCommitted），事务中的修改，即使没提交对其他事务也是可见的。事务可能读取未提交的数据，造成脏读

数据库相关的知识，看了《高性能MySQL》和《数据库系统实现》两本。两本书综合看效果更好。 《高性能MySQL》从使用的角度入手，《数据库系统实现》从原理的角度入手。以前学习数据库相关的知识时有个执念，一定要弄明白它是怎么实现的，就直接买了一个《MySQL内核:Innodb存储引擎》,结果看不懂，束之高阁。 数据库的知识，个人觉得如下的顺序比较合理。 硬盘 《数据库系统实现》在第二章就单独用一章的篇幅讲解磁盘的存储原理。这是因为计算机内置组件中具备持久存储能力的只有硬盘，软件屈从于硬件。因此理解磁盘的存储特点才能理解软件设计背后的逻辑。磁盘存储有如下的特点: 特性A:相比CPU的延迟，磁盘延迟非常非常大。 在《性能之巅》中有做过对比，对于3.3GHz的CPU, 一个指令周期为0.3ns；机械硬盘一次I/O的延迟为1～10ms。这个差距有多大，如果一个CPU指令周期为1s, 那么机械硬盘一次I/O的延迟为1～12个月。真是等到花儿都谢了。 特性B:磁盘是块设备，每次写入都是按块来的。通常一个块为512byte。即使用硬盘，得注意 不能用轮船只运输一个土豆到美国 。 特性C:顺序IO的性能远远高于随机IO的性能。因为顺序IO避免了寻道时间和旋转延迟。 上述的特性不仅影响了数据库的设计，更是深刻影响了操作系统的设计，例如 page cache 读写 数据库的操作基本上就是更高阶的读写:

Spring的配置式事务可以把 多个操作数据库的方法 配置在一个事务中。 Spring的事务是什么?与数据库的事务是否一样？ 本质上其实是同一个概念, spring的事务是对数据库的事务的封装 ,最后本质的实现还是在数据库,假如数据库不支持事务的话,Spring的事务是没有作用的. 数据库的事务说简单就只有开启,回滚和关闭 。 Spring事务对数据库事务的包装,原理就是拿一个 数据连接 ,根据Spring的事务配置, 操作这个数据连接对数据库进行事务开启,回滚或关闭操作 . Spring除了实现这些,还配合 spring的传播行为对事务进行了更广泛的管理 .其实这里还有个重要的点,那就是事务中涉及的隔离级别,以及spring如何对数据库的隔离级别进行封装. MySql中的事务嵌套 1、 Mysql中的事务必须是InnoDB 、Berkeley DB引擎，myisam不支持。 2、Mysql是 不支持嵌套事务 的，开启了一个事务的情况下，再开启一个事务，会 隐式的提交上一个事务 。 3、Mysql默认是autocommit=1，也就是说默认是立即提交，如果想开启事务，先设置autocommit=0，然后用START TRANSACTION、 COMMIT、 ROLLBACK来使用具体的事务。 4、事务控制要成对出现，有开启，必有提交和回滚，如果不匹配导致事务计时器错误

共享锁， 又称为读锁，获得共享锁之后，可以查看但无法修改和删除数据。 排他锁， 又称为写锁、独占锁，获得排他锁之后，既能读数据，又能修改数据。 为什么要加锁 很多人都知道，锁是用来解决并发问题的，那么什么是并发问题呢？并发情况下，不加锁会有什么问题呢？ 拿生活中的洗手间举例子，每个洗手间都会有一个门，并且是可以上锁的，当我们进入洗手间之后会把门反锁，当我们出来之后再把锁打开。 当门被锁上之后，其他人只能在门外等待。洗手间之所以要有门锁，就是为了保护隐私的，避免出现多个人同时进入洗手间的情况。 这和数据库中的锁其实是一样的，为了避免多个事务同时操作数据库导致数据异常，一般会通过锁机制解决。 在介绍共享锁和排他锁之前，我们先来大个比方，前面已经用了一个洗手间的例子，那么就继续这个例子。一般情况下，我们进入洗手间有可能做一下几件事：洗手、化妆、上厕所等，其实只要上厕所这件事是极度隐私的，而其他事没有那么隐私。 我们可以认为洗手间就是一个数据库表，而洗手间内部的设施就是数据库表中的数据。我们每个想要进入洗手间的人都是一个事务，简单的洗手、化妆等操作可以认为是读操作，而上厕所操作可以认为是写操作。 共享锁 前面简单介绍了数据库与洗手间之间的类比关系，那么接下来继续分析什么是共享锁。 有些时候，如果我们进入洗手间只是想洗手的话，我们一般不会锁门。而其他人也可以进来洗手、化妆等。但是

MySQL的四种事务隔离级别 一:事务的基本要素 原子性(Atomic):事务开始后所有操作,要么全部做完,要么全部不做,不可能停滞在中间环节.事务执行过程中出错,会回滚到事务开始前的状态,所有的操作就像没有发生一样. 一致性(consistent):事务开始前和结束后,数据库的完整性约束没有被破坏.比如A向B转账,不可能A扣了钱,B却没有收到. 隔离性(isolation):同一时间,只允许一个事务请求同意数据,不同事务之间彼此没有任何干扰.比如A正在从一张银行卡取钱,在A取钱的过程结束前,B不能 持久性(durable):事务完成后,事务对数据库的所有更新将被保存到数据库,不能回滚. 二:事务的并发问题 脏读:事务A读取了事务B更新的数据,然后B回滚操作,那么A读取到的数据是脏数据 不可重复读:事务A多次读取同一数据,事务B在事务A多次读取的过程中,对数据做了更新并提交,导致事务A多次读取同一个数据时,结果不一致 幻读:系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级,但是系统管理员B就在这个时候插入了一条具体分数的记录,当系统管理员A改完分数结束后发现还有一条记录没有改过来,就好像发生了幻觉一样. 小结：不可重复读的和幻读很容易混淆，不可重复读侧重于修改，幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表 三

分布式事务是企业集成中的一个技术难点，也是每一个分布式系统架构中都会涉及到的一个东西，特别是在这几年越来越火的微服务架构中，几乎可以说是无法避免。 本篇文章将通过详解分布式事务的一致性，以及分布式事务实战解决方案，帮助大家搞懂分布式事务，推荐收藏。 01 为什么需要分布式事务 由于近十年互联网的发展非常迅速，很多网站的访问越来越大，集中式环境已经不能满足业务的需要了，只能按照业务为单位进行数据拆分(包含：垂直拆分与水平拆分)，以及按照业务为单位提供服务，从早期的集中式转变为面向服务架构的分布式应用环境。 举一个典型的例子，阿里的淘宝网站随着访问量越来越大，只能按照商品、订单、用户、店铺等业务为单位进行数据库拆分，以及按照业务为单位提供服务接口。 这个时候 为了完成一个简单的业务功能，比如：购买商品后扣款，有可能需要横跨多个服务，涉及用户订单、商品库存、支付等多个数据库，而这些操作又需要在同一个事务中完，这就涉及到到了分布式事务。 本质上来说，分布式事务就是为了保证不同资源服务器的数据一致性。 02 分布式的一致性理论 最早加州大学伯克利分校 Eric Brewer教授提出一个分布式系统特性的CAP理论。 1.CAP 理论的不可能三角 一致性（Consistency） 可用性（Availability） 分区容错性（Partition tolerance） 在分布式系统中

各位老铁们，你们有没有想老张，最近老张的才华被工作的繁忙所限制了，所以一直没时间更博，今儿个时隔数日我们终于再次见面啦（很开心）！最近有部特别火的宫廷戏，不知道大家有没有看，剧名叫做《延禧攻略》，讲述得是一个宫女，一路过关斩将，最后成为皇上最宠爱的令贵妃的故事。加上我本人巨爱这类题材，所以痴迷得不得了。（好像暴露了自己没有更博的真正原因哈哈）。宫廷类的剧，都是后宫嫔妃之间的尔虞吾诈，勾心斗角，有你没我，有我没你的残酷事实。胜者为王，败者为寇这种思想好像从古代就一直延续到今日。非要分出个胜负，分出个谁好，谁坏才罢休。 在数据库领域也会有此类问题，老张我混迹开源数据库圈多年。MySQL数据库占领着开源数据库的头把交椅，MongoDB占领着NoSQL数据库的第一位。我们来看下数据库的整体排名情况； 两者都是第一，所有总会拿来比较。也会经常被人问及到诸如此类的问题MongoDB4.0已经问世了，而且支持事务了，是不是将来可以取代MySQL了。MySQL和MongoDB哪个数据库好用啊。今天老张想通过这篇文章，带着大家全方位解读MySQL与MongoDB的区别。让有困惑的老铁们明白，没有谁替代谁，只有哪个场景更适合谁。 我们从下面四个方向依次阐明两者的区别。只有更了解彼此，让能更好地利用它们的功能性。 第一部分：数据库概述 我们先来了解一下MySQL这个数据库；