事务隔离级别

环境 MySQL5.5 现象 A.数据更新或新增后数据经常自动回滚。 B.表操作总报 Lock wait timeout exceeded 并长时间无反应 解决方法 A.应急方法： show processlist; kill掉出现问题的进程 B.根治方法： select * from innodb_trx 查看有是哪些事务占据了表资源。 C.我的方法：设置MySQL锁等待超时 innodb_lock_wait_timeout=50 ，autocommit=on 该类问题导致原因 据我分析,Mysql的 InnoDB存储引擎是支持事务的，事务开启后没有被主动Commit。导致该资源被长期占用，其他事务在抢占该资源时，因上一个事务的锁而导致抢占失败！因此出现 Lock wait timeout exceeded 接下来是转载的内容 转载: http://blog.sina.com.cn/s/blog_6bb63c9e0100s7cb.html MySQL 5.5 -- innodb_lock_wait 锁 等待 记得以前，当出现：ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction， 要解决是一件麻烦的事情 ； 特别是当一个SQL执行完了，但未COMMIT，后面的SQL想要执行就是被锁

在Spring中，声明式事务是通过事务属性(transaction attribute)来定义的。事务属性描述了事务策略如何应用到方法上。事务属性包含5个方面： 传播行为 隔离级别 是否只读 事务超时 回滚规则 尽管Spring提供了多种声明式事务的机制，但是所有的方式都依赖这五个参数来控制如何管理事务策略。 （上述内容参考《Spring In Action》第三版）。 对于声明式事务是使用Spring提供的tx配置命名空间。其中一些声明式事务配置元素依赖于部分Spring的AOP配置元素。 下面是一个具体配置的例子： <tx:advice id="txAdviceHibernate" transaction-manager="txManagerHibernate"> <tx:attributes> <tx:method name="add*" propagation="REQUIRED" rollback-for="Exception" no-rollback-for="" /> <tx:method name="batch*" propagation="REQUIRED" rollback-for="Exception" /> <tx:method name="delete*" propagation="REQUIRED" rollback-for="Exception" />

MySQL 数据库 锁机制简介 数据库锁定机制简单来说就是数据库为了保证数据的一致性而使各种共享资源在被并发访问访问变得有序所设计的一种规则。 对于任何一种数据库来说都需要有相应的锁定机制 ，所以 MySQL 自然也不能例外。 MySQL 数据库由于其自身架构的特点，存在多种数据存储引擎，每种存储引擎所针对的应用场景特点都不太一样，为了满足各自特定应用场景的需求，每种存储引擎的锁定机制都是为各自所面对的特定场景而优化设计， 所以各存储引擎的锁定机制也有较大区别。 一、MySQL有三种锁的级别：页级、表级、行级。 MyISAM 和MEMORY 存储引擎采用的是表级锁； BDB 存储引擎采用的是页面锁，但也支持表级锁； InnoDB 存储引擎既支持行级锁，也支持表级锁，但默认情况下是采用行级锁。 MySQL 这3 种锁的特性可大致归纳如下： 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高, 并发度最低。 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低, 并发度也最高。 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。 二、死锁 死锁是指两个或者两个以上的事务在执行过程中，因争夺资源而造成的一种相互等待的现象。解决死锁最简单的一种方式是超时，即当两个事务相互等待是

--都是之前各位大佬总结好的，我只是肤浅的汇总一下，结合我犯得错误，适合像我一样的萌新看 第一：@Transcation 引入的注解 package org.springframework.transaction.annotation; 首先说一下这个注解生效的条件： 第一：如果在方法上，该方法为公共方法，才会生效 第二：如果在类上，类中的公共方法会生效 第三：spring 事务处理中，同一个类中:A方法（无事务）调B方法（有事务）,事务不生效，具体看https://blog.csdn.net/liming19890713/article/details/79225894 第四：spring 事务处理中，同一个类中:A方法（有事务）调B方法（无事务）,事务生效：具体看 https://blog.csdn.net/jim_007/article/details/82352059，涉及到事务的传播行为 问题场景： 我在一个保存方法里调用了查询方法，导致我查到的数据都是要更新的而不是之前的。 问题原因：幻读 简单的解决方法： 第一：注解事务设置隔离级别 第二：数据库事务设置隔离级别 拓展：事务的隔离级别都有什么？除了幻读还有什么？ https://www.cnblogs.com/xiarongjin/p/8405510.html 注意：再看幻读和重复读注意操作的区别，他俩很相像 来源：

1、MySQL的复制原理以及流程 (1)、复制基本原理流程 1. 主：binlog线程——记录下所有改变了数据库数据的语句，放进master上的binlog中； 2. 从：io线程——在使用start slave 之后，负责从master上拉取 binlog 内容，放进 自己的relay log中； 3. 从：sql执行线程——执行relay log中的语句； (2)、MySQL复制的线程有几个及之间的关联 MySQL 的复制是基于如下 3 个线程的交互（ 多线程复制里面应该是 4 类线程）： 1. Master 上面的 binlog dump 线程，该线程负责将 master 的 binlog event 传到slave； 2. Slave 上面的 IO 线程，该线程负责接收 Master 传过来的 binlog，并写入 relay log； 3. Slave 上面的 SQL 线程，该线程负责读取 relay log 并执行； 4. 如果是多线程复制，无论是 5.6 库级别的假多线程还是 MariaDB 或者 5.7 的真正的多线程复制， SQL 线程只做 coordinator，只负责把 relay log 中的 binlog读出来然后交给 worker 线程， woker 线程负责具体 binlog event 的执行； (3)

事务四大特性 原子性：不可分割的操作单元，事务中所有操作，要么全部成功；要么撤回到执行事务之前的状态 一致性：如果在执行事务之前数据库是一致的，那么在执行事务之后数据库也还是一致的； 隔离性：事务操作之间彼此独立和透明互不影响。事务独立运行。这通常使用锁来实现。一个事务处理后的结果，影响了其他事务，那么其他事务会撤回。事务的100%隔离，需要牺牲速度。 持久性：事务一旦提交，其结果就是永久的。即便发生系统故障，也能恢复。 MySQL的事务隔离级别 未提交读(Read Uncommitted)：允许脏读，其他事务只要修改了数据，即使未提交，本事务也能看到修改后的数据值。也就是可能读取到其他会话中未提交事务修改的数据 提交读(Read Committed)：只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别 (不重复读)。 可重复读(Repeated Read)：可重复读。无论其他事务是否修改并提交了数据，在这个事务中看到的数据值始终不受其他事务影响。 串行读(Serializable)：完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞 MySQL数据库(InnoDB引擎)默认使用可重复读（ Repeatable read) 索引 数据库索引，是数据库管理系统中一个排序的数据结构，以协助快速查询、更新数据库表中数据。索引的实现通常使用 B_TREE。B

一、SQL在数据库中的执行过程 二、执行计划 1. ACID 原子性：一个事务（transaction）中的所有操作， 要么全部完成，要么全部不完成 ，不会结束在中间某个环节。事务在执行过程中发生错误，会被恢复（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。 一致性：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。 隔离性：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。 持久性：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。 2. 锁 2.1.按照对数据操作的类型分 读锁：也称为共享锁，针对同一资源，多个读操作是可以并行进行的，并且互不影响。 写锁：也称排它锁。 当前线程写数据的时候，会阻断其他线程来读数据和写数据 2.2 按照 粒度来分 表锁：就是锁整个表（myisam） 行锁：就是锁单独某个表中的某一行(innodb) 叶锁：他是鉴于表锁和行数之间的一种粒度

再次之前自认为我对数据库事务和隔离级别很熟悉了，至少以前整理过，看过网上很多文章，有些带有命令行操作的印象挺深，但是事务传播（包块调用外部系统服务）、分布式锁、mybatis一级缓存等一起存在业务代码中，导致了很多看起来听不可思议的问题，这都是线上案例。 项目中架构师是否跟你说类似的话，事务最好不要嵌套,为什么？如果这样的话事务传播应如何使用，为了方便本片先将事务相关的基础知识做下汇总： 数据库事务ACID特性 1）原子性（Atomicity）：事务开始后所有操作，要么全部做完，要么全部不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有发生一样。也就是说事务是一个不可分割的整体，就像化学中学过的原子，是物质构成的基本单位。 2）一致性（Consistency）事务开始前和结束后，数据库的完整性约束没有被破坏 。比如A向B转账，不可能A扣了钱，B却没收到。 3） 隔离性（Isolation）：同一时间，只允许一个事务请求同一数据，不同的事务之间彼此没有任何干扰。比如A正在从一张银行卡中取钱，在A取钱的过程结束前，B不能向这张卡转账（其实是隔离级别中的串行化）。 4）持久性（Durability）：事务完成后，事务对数据库的所有更新将被保存到数据库，不能回滚。 事务4种隔离级别 1):Read Uncommitted

事务 　　是作为一个逻辑单元执行的一系列操作，一个逻辑工作单元必须有四个属性，称为 ACID（原子性、一致性、隔离性和持久性）属性. 1、A (Atomicity) 原子性 事务必须是原子工作单元；对于其数据修改，要么全都执行，要么全都不执行。 2、C (Consistency)一致性 事务在完成时，必须使所有的数据都保持一致状态。在相关数据库中，所有规则都必须应用于事务的修 改，以保持所有数据的完整性。事务结束时，所有的 内部数据结构（如 B 树索引或双向链表）都必须是正确的。 3、I (Isolation) 隔离性 并发事务所做的修改必须与任何其他并发事务所做的 修改隔离。事务识别数据时数据所处的状态，要么是 另一并发事务修改它之前的状态，要么是第二个事务 修改它之后的状态，事务不会识别中间状态的数据。 4、D (Durability) 持久性 事务完成之后，它对于系统的影响是永久性的。该修 改即使出现系统故障也将一直保持。 锁 锁定是 Microsoft SQL Server数据库引擎用来同步多个用户同时对同一个数据块的访问的一种机制。 在事务获取数据块当前状态的依赖关系（比如通过读取或修改数据）之前，它必须保护自己不受其他事务对同一数据进行修改的影响。事务通过请求锁定数据块来达到此目的。锁有多种模式，如共享或独占 1、脏读 某个事务读取的数据是另一个事务正在处理的数据

一个数据库可能拥有多个访问客户端，这些客户端并发访问数据库时，若没有采取必要的隔离措施，存在以下问题，这些问题分为5类，包括3类数据读问题：脏读、不可重复读和幻读。两类数据更新问题：第一类丢失更新、第二类丢失更新。 1.脏读 2.不可重复读 不可重复读是指A事务读取了B事务已经提交的 更改数据 。假如A在取款事务的过程中，B往该账户转账100，A两次读取的余额发生不一致。 3.幻读 A事务读取B事务提交的 新增数据 注意：不可重复读和幻读的区别是： 前者是指读到了已经提交的事务的更改数据（修改或删除），后者是指读到了其他已经提交事务的新增数据。 对于这两种问题解决采用不同的办法，防止读到更改数据，只需对操作的数据添加行级锁，防止操作中的数据发生变化；二防止读到新增数据，往往需要添加表级锁，将整张表锁定，防止新增数据（oracle采用多版本数据的方式实现）。 4.第一类丢失更新 这时候取款事务A撤销事务，余额恢复为1000，这就丢失了更新。 5.第二类丢失更新 为了解决上述问题，数据库通过 锁机制 解决并发访问的问题。根据锁定对象不同：分为行级锁和表级锁；根据并发事务锁定的关系上看：分为共享锁定和独占锁定，共享锁定会防止独占锁定但允许其他的共享锁定。而独占锁定既防止共享锁定也防止其他独占锁定。为了更改数据，数据库必须在进行更改的行上施加行独占锁定，insert、update