事务

MySQL行为 在MySQL中，存在两个可以控制行为的变量，它们分别是AUTOCOMMIT变量和TRANSACTION ISOLACTION LEVEL变量。 自动提交 在MySQL中，如果不更改其自动提交变量，则系统会自动向数据库提交结果，用户在执行数据库操作过程中，不需要使用START TRANSACTION语句开始事务，应用COMMIT或者ROLLBACK提交事务或执行回滚操作。 事务的孤立级 事务具有独立的空间，在MySQL服务器中，用户通过不同的会话执行不同的事务，在多用户环境中，许多RDBMS会话在任意指定时刻都是活动的。为了使这些事务互不影响，保证数据库性能不受到影响，采用事务的孤立级是十分有必要的。 基于ANSI/ISO SQL规范，MySQL提供4种孤立级： SERIALIZABLE（序列化） REPEATABLE READ（可重读） READ COMMITTED（提交后读） READ UNCOMMITTED（未提交读） 修改事务的孤立级 在MySQL中，可以使用TRANSACTION ISOLATION LEVEL变量修改事务孤立级，其中，MySQL的默认孤立级为REPEATABLE READ（可重读），用户可以使用SELECT命令获取当前事务孤立级变量的值， 其命令如下： SELECT @@tx_isolation ; 查询高速缓存 在MySQL中

在分布式系统中，实现强一致性并不容易。即使2PC、3PC阶段提交，也无法保证绝对的强一致性。 我们也不能因为极小的不一致性概率，导致系统整体性能低下，或者扩展性受到影响，并且架构也变得极其复杂。因此，在2PC/3PC提交缺乏大规模应用的情况下，最终一致性是一个较好的方案，在业界得到了大量使用。 一、重试机制 如下图所示，Service Consumer 同时调用 Service A 和 Service B，如果Service A 调用成功，Service B 调用识别，为了保证最终一致性，最简单的办法是重试。 重试的时候，要注意设置Service Consumer 的超时时间， 避免长时间等待或卡死，耗尽资源。 Consumer 重试时，需要注意如下几个方面： 超时时间； 重试的次数； 重试的间隔时间； 重试间隔时间的衰减度； 具体实现细节，可以参考《 基于Spring-tryer 优雅的重试方案》。 二、本地记录日志 通过本地记录日志，然后收集到分布式监控系统或者其他后端系统中，启动一个定期检查的工具。根据实际情况，可以选择人工处理。 日志格式：TranID-A-B-Detail TransID为事务ID，可以生成一个随机序列号； Detail 为数据的详细内容； 如果调用A成功，则记录 A success； 如果调用B失败，或者出现故障，没有记录等等，也就是日志中没有B

21幂等性 就是对资源的操作，无论操作一次还是多次，其资源本身不发生变化 20base理论 针对cap中ca不能同时存在而制定的 https://m.aliyun.com/yunqi/articles/692238 19cap理论 http://www.ruanyifeng.com/blog/2018/07/cap.html 18 17数据库本地事务实现原理 https://www.cnblogs.com/takumicx/p/9998844.html ，对事务将解的非常到位 遗留问题， d,事务的一直性与cap的一致性有何区别？ c如果实事务a正在提交，且由于锁冲突一直在提交中，那么另外一个事务能否读到部分数据？ a如果我执行成功的修改语句但未提交到，重启数据那么数据是否有问题？ b如果提交的时候有锁冲突，那么提交后会不会提示提交操作失败？ https://blog.csdn.net/qq360694660/article/details/88695365 16全链路监控 微服务中也很有必要，用于定位问题，服务较多情况可以在错误信息中加上前缀，以便定位错误发生在哪个系统上，此外在记录日志时，需标记错误来源，以及详细信息 422页，倒数第8行。 15ELK 专门分析日志的工具 14restful api 服务端人员开发的接口，需要用api的形式提供给前端人员或者其他人员，可以用这个

1、事务概念： 　　　　　　 一组sql语句操作单元，组内所有SQL语句完成一个业务，如果整组成功：意味着全部SQL都实现；如果其中任何一个失败，意味着整个操作都失败。失败，意味着整个过程都是没有意义的。应该是数据库回到操作前的初始状态。这种特性，就叫“事务”。 2、为什么要存在事务？ 　　 1）失败后，可以回到开始位置 　　2）没都成功之前，别的用户（进程，会话）是不能看到操作内的数据修改的 3、事务4大特征ACID： 　　1）原子性[atomicity]：功能不可再分，要么全部成功，要么全部失败 　　2）一致性[consistency]：事务要求所有的DML语句操作的时候，必须保证同时成功或者同时失败 　　3）隔离性[isolation]：事务A和事务B之间具有隔离性 　　4）持久性[durability]：是事务的保证，事务终结的标志(内存的数据持久到硬盘文件中) 3、相关概念： 【SQL执行过程】1）执行阶段 　　2）将执行结果，提交到数据库的阶段 其中我们的事务日志，就是保存执行阶段的结果，如果用于选择提交，则才将执行的结果提交到数据库。 默认的执行方式叫做，自动提交。执行完毕，自动完成提交工作。如果你想要所有SQL语句全部成功，就需要关闭自动提交功能。 “自动提交”：存在一个系统变量，Autocommit可以对自动提交进行设置。 4、事务操作： 方法一： show

【事务】一组SQL语句操作单元， 组内所有SQL语句，完成一个业务 。 若整组成功，意味着组内的全部操作都成功； 反之，若其中任何一条语句失败，意味着整个操作都失败。 操作失败，意味着整个过程都是没有意义的，应使数据库回到操作前的初始状态。 【point】 1. 失败后，能回到开始位置； 2. 成功之前，其他用户（进程、规划）不能看到操作内的修改。 【思路】在一组操作之前，设计一个记号（备份点）。 【实现】利用 innodb 存储引擎的“事务日志”功能。 执行分为2个阶段： 1. 执行阶段； 2. 将执行结果提交给数据库的阶段； 其中，事务日志便是将执行阶段的结果保存，若用户选择提交，才将执行结果提交给数据库。 （默认的执行方式：自动提交） 需要关闭自动提交功能（存在一个系统变量，autocommit 可以对自动提交进行配置） 1 set autocommit = 0 ; // 0 意味着关闭自动提交功能；1 意味着开启 若成功，执行 commit 提交结果； 若失败，执行 rollback ，回到起始位置。 -------------------------------------------------------------------------- 【 常用的事务指令 】 1. start transaction 开启事务（作用：关闭自动提交）。 特点：若事务结束了

事务:一组sql语句操作单元，组内所有sql语句完成一个业务.注意只有innodb和bdb可以使用事务安全 如果整组成功则意味着全部sql语句都实现。如果其中任何一个失败，意味着整个操作失败。失败意味着整个过程都是没意义的，数据库应该回到最初始的状态。上面的特性，就是事务。 如何处理:失败后，可以回到开始位置、没有成功之前，别的用户(进程，对话)是不能看到操作内的数据修改的 思路:就是在一组操作之前，设计一个记号(备份点)。操作成功就让别人看到数据的修改，如果失败别人就不能看到修改，而且回到记号位置。 实现:利用innodb存储引擎的事务日志功能。 sql执行分为2个阶段:一个是执行阶段一个是将执行结果提交到数据库的阶段。其中我们的事务日志，就是保存执行阶段的结果。如果可以用，则将执行的结果提交到数据库 数据库默认的执行方式是：自动提交(autocommit)。执行完后自动完成提交工作。想要完成事务安全就需要关闭自动提交功能。set autocommit=0; 例：交班费业务30元:包含两条sql语句update `sm_student` set `s_money`=`s_money`-30 where id=1; update `class` set `c_money`=`c_money`+30 where id=1;

ACID:Atomic、Consistent、Isolated、Durable 存储程序提供了一个绝佳的机制来定义、封装和管理事务。 1，MySQL的事务支持 MySQL的事务支持不是绑定在MySQL服务器本身，而是与存储引擎相关： MyISAM：不支持事务，用于只读程序提高性能 InnoDB：支持ACID事务、行级锁、并发 Berkeley DB：支持事务 隔离级别： 隔离级别决定了一个session中的事务可能对另一个session的影响、并发session对数据库的操作、一个session中所见数据的一致性 ANSI标准定义了4个隔离级别，MySQL的InnoDB都支持： READ UNCOMMITTED：最低级别的隔离，通常又称为dirty read，它允许一个事务读取还没commit的数据，这样可能会提高性能，但是dirty read可能不是我们想要的 READ COMMITTED：在一个事务中只允许已经commit的记录可见，如果session中select还在查询中，另一session此时insert一条记录，则新添加的数据不可见 REPEATABLE READ：在一个事务开始后，其他session对数据库的修改在本事务中不可见，直到本事务commit或rollback。在一个事务中重复select的结果一样，除非本事务中update数据库。 SERIALIZABLE

前言 读这篇文章之前可以先了解一下 MySQL中InnoDB数据结构 一、InnoDB引擎对隔离级别的支持 事务隔离级别 脏读 不可重复读 幻读 读未提交（read-uncommitted） 可能 可能 可能 不可重复读（read-committed） 不可能 可能 可能 可重复读（repeatable-read） 不可能 不可能 InnoDB不可能 串行化（serializable） 不可能 不可能 不可能 隔离级别到底如何实现？ 二、锁的介绍 1、表锁、行锁 通过锁来管理不同事务对共享资源的并发访问 表锁与行锁的区别： 锁定粒度：表锁 > 行锁 加锁效率：表锁 > 行锁 冲突概率：表锁 > 行锁 并发性能：表锁 < 行锁 InnoDB存储引擎只支持行锁，表锁是通过锁住所有行实现 2、InnoDB锁类型 共享锁（行锁，又称S锁）：Shared Locks 又称为读锁，简称S锁，顾名思义，共享锁就是多个事务对于同一数据可以共享一把锁， 都能访问到数据，但是只能读不能修改。 select * from teachers WHERE id = 1 LOCK IN SHARE MODE ; commit / rollback 排它锁（行锁，又称X锁）：Exclusive Locks 又称为写锁，简称X锁，排他锁不能与其他锁并存，如一个事务获取了一个数据行的排他 锁

Oracle临时表就像它的名字一样，主要是用于临时的用途。它主要用来存储中间数据。对于不同的用户，表的数据是隔离的并在用户提交或者断开会话自动TRUNCATE。 Oracle临时表分为会话级和事务级两种。 1）ON COMMIT DELETE ROWS 事务级的临时表，这种类型的临时表与事务有关，当进行事务提交或者事务回滚的时候，临时表的数据将自行截断，即当COMMIT或ROLLBACK时，数据就会被TRUNCATE掉。 2）ON COMMIT PRESERVE ROWS 会话级的临时表，它和你当前会话有关系，当前SESSION不退出的情况下，临时表中的数据就还存在，临时表的数据只有当你退出当前SESSION的时候才被TRUNCATE 。 会话级的临时表 【语法】 Create Global Temporary Table Table_Name (the aggregation SQL statement) On Commit Preserve Rows； 事务级的临时表 【语法】 Create Global Temporary Table Table_Name (the aggregation SQL statement) On Commit Delete Rows； 【临时表的特点】 临时表数据自动清空后，但是临时表的结构以及元数据还存储在用户的数据字典中

并发操作可能破坏事务的隔离性，带来的数据不一致性包括三类： 1） 丢失修改 2） 不可重复读 3） 读“脏”数据 锁 是网络数据库中的一个非常重要的概念，当多个用户同时对数据库并发操作时，会带来数据不一致的问题，所以，锁主要用于 多用户环境下保证数据库完整性和一致性 。 数据库锁出现的目的： 处理并发问题 从 数据库系统 角度，基本的锁类型有两种: 排它锁(Exclusive Lock) 和 共享锁(Shared Lock) . 排它锁（X锁） ，也称为写锁，表示对数据进行写操作。 当事务T对数据A加上X锁时,只允许事务T读取和修改数据A 共享锁（S锁） ，也称为读锁，用于所有的只读数据操作。 当事务T对数据A加上S锁时,其他事务只能再对数据A加S锁,而不能加X锁,直到T释放A上的S锁。 若事务T对数据对象A加了S锁,则T就可以对A进行读取,但不能进行更新（读锁）,在T释放A上的S锁以前,其他事务可以再对A加S锁,但不能加X锁,从而可以读取A,但不能更新A。 封锁协议 ：在运用X锁和S锁对数据对象加锁时，还需要约定一些规则 ，例如何时申请X锁或S锁、持锁时间、何时释放等。称这些规则为封锁协议（Locking Protocol）。对封锁方式规定不同的规则，就形成了各种不同的封锁协议。 1）一级封锁协议 一级封锁协议是：事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放