mysql事务

@Transactional 事务管理的目的 在出现异常的情况下，保证数据的一致性；数据提交操作回滚至异常发生前的状态 事务管理的方式： Spring（Spring Framework 提供对事务管理的抽象接口） 支持两种事务管理方式： 编程式事务管理：使用TransactionTemplate或PlatformTransactionManager实现 声明式事务管理：建立在AOP之上的。其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务（此处取决于事务的传播行为），在执行完目标方法之后根据执行情况提交或者回滚事务（执行成功则提交，失败则进行实物的回滚） 编程式事务管理优势：可以控制事务的粒度，最细粒度到代码块级别； 声明式实物管理优势：在方法外进行声明，事务控制的代码不会与业务逻辑代码混在一起，最细粒度到方法级别（解决方法：可以将需要进行事务管理的代码块独立为方法，通过方法间调用实现）；符合spring倡导的非侵入式的开发方式，即业务处理逻辑代码与事务管理代码不放在一起 声明式事务管理实现方式： 基于tx和aop名字空间的xml配置文件 // 基本配置 <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns

Mysql的锁机制 在Mysql中，不同的存储引擎支持不同的锁机制。比如，MyISAM和MEMORY存储引擎采用的是表级锁(table-level locking)；InnoDB存储引擎既支持行级锁(row-level locking)，也支持表级锁，但默认情况下是采用行级锁。 表级锁： 开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。 行级锁： 开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。 1.MyISAM表锁 MyISAM默认加的是表锁 MySQL的表级锁有两种模式： 表共享读锁（Table Read Lock） 和 表独占写锁（Table Write Lock） 。 对MyISAM表的读操作，不会阻塞其他用户对同一表的读请求，但会阻塞对同一表的写请求；对 MyISAM表的写操作，则会阻塞其他用户对同一表的读和写操作；MyISAM表的读操作与写操作之间，以及写操作之间是串行(共享读锁（S）之间是兼容的，但共享读锁（S）与排他写锁（X）之间，以及排他写锁（X）之间是互斥的)的！ 写锁阻塞读 :当一个线程获得对一个表的写锁之后，只有持有锁的线程可以对表进行更新操作。其他线程的读写操作都会等待，直到锁释放为止。 读锁阻塞写 :一个session使用lock table给表加读锁，这个session可以锁定表中的记录

事务概述 MySQL 事务, 主要用于处理操作量大，复杂度高的数据。比如说，在人员管理系统中，你删除一个人员，既需要删除人员的基本资料，也要删除和该人员相关的信息，如信箱，文章等等，如果操作就必须同时操作成功，如果有一个不成功则所有数据都不动。这时候数据库操作语句就构成一个 事务 。事务主要处理数据的 增删改 操作。 定义 一件事从开始发生到结束的过程 作用 确保数据操作过程中的一致性、完整性、准确性、有效性 事务四大特性 原子性（atomicity） 一个事务必须视为一个不可分割的 最小工作单元 ，对于一个事务来说，不可能只执行其中的一部分操作,整个事务中的所有操作要么全部提交成功，要么全部失败回滚 一致性（consistency） 事务完成时，数据必须处于一致状态，数据的完整性约束没有被破坏。 隔离性（isolation） 数据库允许 多个并发事务 同时对其数据进行读写和修改的能力，而多个事务相互独立。隔离性可以防止多个事务并发执行时由于 交叉执行而导致数据的不一致 。 持久性（durability） 一旦事务提交，则其所做的修改就会 永久保存到数据库 中。此时即使系统崩溃，修改的数据也不会丢失。 事务操作 开启事务 mysql>begin; # 方法1 mysql>start transaction; # 方法2 开始执行事务中的若干条SQL命令（增删改） 终止事务

锁概念 ： 当高并发访问同一个资源时，可能会导致数据不一致，需要一种机制将用户访问数据的顺序进行规范化，以保证数据库数据的一致性。锁就是其中的一种机制。 举例 ：以买火车票为例，火车票可面向广大消费者，每位用户都可以查询余票数量、购买火车票 ... 但最终购票成功的仅有一位用户，处于购票高峰期时会出现很多用户同时抢夺同一张票的现状，为了避免出现一张火车票被多个用户购买成功的情况，当第一位用户进入购票流程时，就将数据库锁定，让别的用户无法修改，只有当第一位用户购票成功或取消购票之后，才会解除数据库的锁定，此时别的用户就可继续进行操作。这样就保证了一张火车票只能被一个用户购买。 悲观锁： 一般代指 数据库锁机制, 类似于我们在多线程资源竞争时添加的互斥锁，较容易出现死锁现象。它对于数据被外界修改持保守态度， 认为数据随时会修改，所以整个数据处理中需要将数据加锁。 悲观锁一般都是依靠关系数据库提供的锁机制实现。 悲观锁按使用性质划分： 数据库的操作可归纳为两种：读和写。当多个事务同时读取一个对象时，不会产生有冲突。但同时读和写，或者同时写会产生冲突。因此为提高数据库的并发性能，定义三种锁 共享锁（ Share locks简记为S锁 ） ：也称 读锁 ，事务A给对象T加S锁， 其他事务也只能对T加S ， 多个事务可以同时读，但不能有写操作 ，直到A释放S锁。 　　　　地球语言 ：

前两天面试，问到了四种隔离级别，当时觉得大多数数据库都为read committed，结果没想到mysql是个例外。在此做一下隔离级别和各种数据库锁的使用。 首先说一下ACID四大特性： 四大特性 · 原子性 　　事务必须是原子工作单元；对于其数据修改，要么全都执行，要么全都不执行。通常，与某个事务关联的操作具有共同的目标，并且是相互依赖的。如果系统只执行这些操作的一个子集，则可能会破坏事务的总体目标。原子性消除了系统处理操作子集的可能性。 　　· 一致性 　　 事务在完成时，必须使所有的数据都保持一致状态。在相关数据库中，所有规则都必须应用于事务的修改，以保持所有数据的完整性。事务结束时，所有的内部 数据结构 （如 B 树索引或双向链表）都必须是正确的。某些维护一致性的责任由应用程序开发人员承担，他们必须确保应用程序已强制所有已知的完整性约束。例如，当开发用于转帐的应用程序时，应避免在转帐过程中任意移动小数点。 　　· 隔离性 　　由并发事务所作的修改必须与任何其它并发事务所作的修改隔离。事务查看数据时数据所处的状态，要么是另一并发事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看中间状态的数据。这称为可串行性，因为它能够重新装载起始数据，并且重播一系列事务，以使数据结束时的状态与原始事务执行的状态相同。当事务可序列化时将获得最高的隔离级别。在此级别上

转自 http://blog.sina.com.cn/s/blog_499740cb0100ugs7.html MySQL InnoDB事务的隔离级别 有四级，默认是“可重复读”（REPEATABLE READ）。 未提交读（READ UNCOMMITTED）。另一个事务修改了数据，但尚未提交，而本事务中的SELECT会读到这些未被提交的数据（脏读）。 提交读（READ COMMITTED）。本事务读取到的是最新的数据（其他事务提交后的）。问题是，在同一个事务里，前后两次相同的SELECT会读到不同的结果（不重复读）。 可重复读（REPEATABLE READ）。在同一个事务里，SELECT的结果是事务开始时时间点的状态，因此，同样的SELECT操作读到的结果会是一致的。但是，会有幻读现象（稍后解释）。 串行化（SERIALIZABLE）。读操作会隐式获取共享锁，可以保证不同事务间的互斥。 四个级别逐渐增强，每个级别解决一个问题。 脏读，最容易理解。另一个事务修改了数据，但尚未提交，而本事务中的SELECT会读到这些未被提交的数据。 不重复读。解决了脏读后，会遇到，同一个事务执行过程中，另外一个事务提交了新数据，因此本事务先后两次读到的数据结果会不一致。 幻读。解决了不重复读，保证了同一个事务里，查询的结果都是事务开始时的状态（一致性）。但是，如果另一个事务同时提交了新数据

前两天面试，问到了四种隔离级别，当时觉得大多数数据库都为read committed，结果没想到mysql是个例外。在此做一下隔离级别和各种数据库锁的使用。 首先说一下ACID四大特性： 四大特性 · 原子性 　　事务必须是原子工作单元；对于其数据修改，要么全都执行，要么全都不执行。通常，与某个事务关联的操作具有共同的目标，并且是相互依赖的。如果系统只执行这些操作的一个子集，则可能会破坏事务的总体目标。原子性消除了系统处理操作子集的可能性。 　　· 一致性 　　 事务在完成时，必须使所有的数据都保持一致状态。在相关数据库中，所有规则都必须应用于事务的修改，以保持所有数据的完整性。事务结束时，所有的内部 数据结构 （如 B 树索引或双向链表）都必须是正确的。某些维护一致性的责任由应用程序开发人员承担，他们必须确保应用程序已强制所有已知的完整性约束。例如，当开发用于转帐的应用程序时，应避免在转帐过程中任意移动小数点。 　　· 隔离性 　　由并发事务所作的修改必须与任何其它并发事务所作的修改隔离。事务查看数据时数据所处的状态，要么是另一并发事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看中间状态的数据。这称为可串行性，因为它能够重新装载起始数据，并且重播一系列事务，以使数据结束时的状态与原始事务执行的状态相同。当事务可序列化时将获得最高的隔离级别。在此级别上

Innodb锁的类型 行锁（record lock） 行锁总是对索引上锁，如果某个表没有定义索引，mysql就会使用默认创建的聚集索引，行锁有S锁和X锁两种类型。 共享锁和排它锁 Innodb锁有两种类型：共享锁(S lock)和排它锁(X lock) 不同事务可以同时对同一行记录加S锁 如果一个事务对某一行记录加X锁，其他事务就不能加S锁或者X锁，从而导致锁等待 使用sql SELECT ... LOCK IN SHARE MODE 可以对一行记录加S锁，sql SELECT ... FOR UPDATE 则是加X锁 意向锁（intention lock） Innodb为了支持多粒度的加锁，允许行锁和表锁同时存在。插入意向锁即是一种表锁，在事务对某一行或者多行加锁之前，必须对这张表加入意向锁（或更强的锁如X锁）。插入意向锁分为： intention shared lock (IS)：表明事务对于这张表的记录有插入S锁的意向 intention exclusive lock (IX)：表明事务对于这张表的记录有插入X锁的意向 插入意向锁和其他表锁兼容性如下： X IX S IS X Conflict Conflict Conflict IX Conflict Compatible Conflict S Conflict Conflict Compatible IS Conflict

锁 数据库系统使用锁是为了支持对共享资源进行并发访问，提供数据的完整性和一致性。 InnoDB存储引擎中的锁 共享锁（S Lock），允许事务读一行数据 排他锁（X Lock），允许事务删除或更新一行数据 兼容性： S与S可以兼容 X不与任何锁兼容 InnoDB支持多粒度锁定，也就是允许行级和表级的锁同时存在。实现方式为通过意向锁（Intention Lock）：如果需要对最细粒度进行加锁，需要在上层粒度加意向锁。 具体举例，如果需要对行加X锁，需要对表、页依次加IX锁。当意向锁遇到等待时，必须等待结束后才能继续对下级加锁。如准备加对一行有S锁的行加S锁，行记录因为原来就有S锁，所以表和页都已经存在了IS锁，首先新的IS锁加在表上，因为IS、IS锁兼容，可以加上；然后再看页锁，同样IS、IS兼容，可以加上；最后看行锁IS与S兼容，那么行记录可以加上S锁。对同样这行有S锁的行加X锁，先加表IX锁，IX与IS兼容，可以加上，页同样，最后IX锁与行记录上的S锁不兼容，因此要等待S锁释放后才能加上X锁。 一致性非锁定读 一致性非锁定读（consistent nonlocking read）是指InnoDB存储引擎通过行多版本控制（multi version）的方式来读取当前执行时间数据库中行的数据。在行记录正在执行DELETE或UPDATE时执行读操作，不会等待锁释放

解决思路： 　　select * from information_schema.innodb_trx 之后找到了一个一直没有提交的只读事务， 　　kill 到了对应的线程后ok 了。 转载自：http://blog.sina.com.cn/s/blog_6bb63c9e0100s7cb.html 在Mysql5.5中，information_schema 库中增加了三个关于锁的表（MEMORY引擎）； 　　innodb_trx ## 当前运行的所有事务 　　innodb_locks ## 当前出现的锁 　　innodb_lock_waits ## 锁等待的对应关系 ## 产生事务，在innodb_trx就有数据 ； mysql> select * from information_schema.innodb_trx G; 如果没有产生锁等待，innodb_lock_waits 和innodb_locks 中没有数据 如果产生所等待，查询这三张表，找到对应线程，杀掉。 来源： https://www.cnblogs.com/luffe/p/7977592.html