mysql事务

Transaction 也就是所谓的事务了，通俗理解就是一件事情。从小，父母就教育我们，做事情要有始有终，不能半途而废。 事务也是这样，不能做一半就不做了，要么做完，要么就不做。也就是说，事务必须是一个不可分割的整体，就像我们在化学课里学到的原子，原子是构成物质的最小单位。于是，人们就归纳出事务的第一个特性：原子性（Atomicity）。我靠，一点都不神秘嘛。 特别是在数据库领域，事务是一个非常重要的概念，除了原子性以外，它还有一个极其重要的特性，那就是：一致性（Consistency）。也就是说，执行完数据库操作后，数据不会被破坏。打个比方，如果从 A 账户转账到 B 账户，不可能因为 A 账户扣了钱，而 B 账户没有加钱吧。如果出现了这类事情，您一定会非常气愤，什么 diao 银行啊！ 当我们编写了一条 update 语句，提交到数据库的一刹那间，有可能别人也提交了一条 delete 语句到数据库中。也许我们都是对同一条记录进行操作，可以想象，如果不稍加控制，就会出大麻烦来。我们必须保证数据库操作之间是“隔离”的（线程之间有时也要做到隔离），彼此之间没有任何干扰。这就是：隔离性（Isolation）。要想真正的做到操作之间完全没有任何干扰是很难的，于是乎，每天上班打酱油的数据库专家们，开始动脑筋了，“我们要制定一个规范，让各个数据库厂商都支持我们的规范！”，这个规范就是

问题场景 什么是事务? 事务是数据库从一个稳定状态变迁到另一个稳定状态的保证，具备 ACID 这 4 个特性： 原子性（Atomicity）：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚到事务开始前的状态。 一致性（Consistency）：在事务开始之前和事务结束以后，数据库的完整性限制没有被破坏。 隔离性（Isolation）：两个事务的执行是互不干扰的，两个事务时间不会互相影响。 持久性（Durability）：在事务完成以后，该事务对数据库所作的更改便持久地保存在数据库之中，并且是完全的。 例如应用程序需要更新多条相关数据时就需要进行事务处理。 什么是分布式事务? 当遇到复杂业务调用时，可能会出现跨库多资源调用(一个事务管理器，多个资源)/多服务调用（多个事务管理器，多个资源），期望全部成功或失败回滚，这就是分布式事务，用以保证“操作多个隔离资源的数据一致性”。 分布式事务与 XA 规范 分布式事务是指会涉及到操作多个数据库的事务，同样必须保证 ACID。其就是将对同一库事务的概念扩大到了对多个库的事务：对同一库的 SQL 操作对应了分布式事务中对一个库的事务。 X/Open XA 定义了分布式事务处理的规范，并由数据库厂商在驱动层面进行实现。XA 规范的基础是两阶段提交协议

https://dev.mysql.com/doc/refman/5.7/en/innodb-deadlocks.html 什么是mysql的死锁？ A deadlock is a situation where different transactions are unable to proceed because each holds a lock that the other needs. Because both transactions are waiting for a resource to become available, neither ever release the locks it holds. 简单来说可以提炼出2个词：环路等待（ each holds a lock that the other needs ）和不可剥夺（ neither ever release the locks it holds ）。 其实广泛意义上死锁的四个必要条件也可以直接简化为上述两个条件，剩下的互斥和请求保持条件只是两个众所周知的补充。 一、一个简单的死锁示例： 会话A： mysql> CREATE TABLE t (i INT) ENGINE = InnoDB; Query OK, 0 rows affected (1.07 sec) mysql> INSERT INTO

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 导读 我们知道可以在线修改全局或会话级的事务隔离级别，也可以修改时不指定GLOBAL/SESSION关键字，而只影响当前会话中的下一个事物，但怎么确认修改生效了呢？ 我们知道，可以分别用 @@global.transaction_isolation 和 @@ session.transaction_isolation来查看全局或会话级隔离级别，或者用 @@transaction_isolation 查看会话级隔离级别。也就是说： @@session.transaction_isolation 和 @@transaction_isolation 二者等价。 在MySQL里，可以在线修改全局或会话级的事务隔离级别，例如这样： 可以看到全局和会话级的隔离级别是不一样的 另外，我们也知道，在修改隔离级别时若不指定 GLOBAL/SESSION 关键字，则只会针对当前会话的下一个事务生效，下一个事务结束后，又会恢复当前会话此前设定的隔离级别。 但可能有些同学不太放心，或者可能就想确认某个事务的隔离级别。接下来，我们一起来看下，怎么查看确认某个事务的隔离级别。 这种情况下，我们就需要借助 information_schema.innodb_trx这个视图了，看下面例子。 最后几点结论： 1、执行 select @@tx

Spring事务管理分为 声明式事务管理 和 编程式事务 管理，声明式事务管理又分为 xml 和 注解 两种配置方式。应该优先选择声明式事务，因为声明式事务对程序代码的影响最小，因此最符合 非侵入式轻量级容器 的理想 。只有在进行少量事务操作时，才应该选择编程式事务管理的方式。 声明式事务管理 xml配置方式 Spring配置文件： <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:aop="http://www.springframework.org/schema/aop" xmlns:tx="http://www.springframework.org/schema/tx" xmlns:context="http://www.springframework.org/schema/context" xsi:schemaLocation=" http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans

事务与并发写 某个正在更新的记录在提交或回滚前不能被其他事物同时更新 先加锁后修改 等待锁释放 事物的ACID 原子性Atomic : 要么全部执行,要么全部不执行,中途数据库发生异常,未提交的事物都被回滚 一致性Consistency : 数据库从一种正确状态转为另一种正确状态,数据库在修改时保证数据的正确性合理性一致性 隔离性Isolation 事务正确提交完成前,中间的任何数据变化对其他的事物都是不可见的 持久性Durability : 事物一旦提交就永久保存…数据库写在事务日志异步更新到磁盘,使用事务日志持久化实现只要是性能方面的考虑 四种隔离级别 1读未提交:读到未提交的数据 2读已提交:两次读取到的数据不一致(不可重复读) 3可重复读 mysql默认隔离级别 4串行化:读写数据会锁表.并发性能低 并发事务问题 脏读,读取他人未提交事物 不可重复读:其他事务对数据进行了修改 幻读:其他事务对数据进行了增加或删除 查看数据库默认的隔离级别 select @ @tx_isolation ; 默认级别可重复读 REPEATABLE - READ 设置隔离级别为–读未提交 set tx_isolation = 'read-uncommitted' ; select @ @tx_isolation ; READ - UNCOMMITTED 读已提交 --解决脏读 set tx

1. 什么是数据库事务 1.1 数据库事务是指作为单个逻辑工作单元执行的一系列操作（SQL语句）。这些操作要么全部执行，要么全部不执行。 1.2 通过ACID实现数据库事务模型 1.2.1 原子性(Atomicity)：事务是数据库的逻辑工作单位，它对数据库的修改要么全部执行，要么全部不执行。 1.2.2 一致性(Consistemcy)：事务执行前后，数据库的状态都满足所有的完整性约束。 1.2.3 隔离性(Isolation)：并发执行的事务是隔离的，保证多个事务互不影响。如果有两个事务，运行在相同的时间内，执行相同的功能，事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。这种属性有时称为串行化，为了防止事务操作间的混淆，必须串行化或序列化请求，使得在同一时间仅有一个请求用于同一数据。通过设置数据库的隔离级别，可以达到不同的隔离效果。 1.2.4 持久性(Durability)：一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。 1.3 事务运行的三种模式 1.3.1 自动提交事务：默认事务管理模式。如果一个语句成功地完成，则提交该语句；如果遇到错误，则回滚该语句。 1.3.2 显式事务：以BEGIN TRANSACTION显式开始，以COMMIT或ROLLBACK显式结束。 1.3.3 隐性事务：当连接以此模式进行操作时

锁兼容性图： 一、锁的粒度： 比较需要注意的是RID/KEY、HoBT/PAGE这两对儿的区别，RID和HoBT是针对堆表的，即没有聚集索引的表。 二、锁的模式： 1.关于其中的S、U、X锁： 共享锁 共享锁（S 锁）允许并发事务在封闭式并发控制下读取 (SELECT) 资源。 资源上存在共享锁（S 锁）时，任何其他事务都不能修改数据。 读取操作一完成，就立即释放资源上的共享锁（S 锁），除非将事务隔离级别设置为可重复读或更高级别，或者在事务持续时间内用锁定提示保留共享锁（S 锁）。 更新锁 更新锁（U 锁）可以防止常见的死锁。 在可重复读或可序列化事务中，此事务读取数据 [获取资源（页或行）的共享锁（S 锁）]，然后修改数据 [此操作要求锁转换为排他锁（X 锁）]。 如果两个事务获得了资源上的共享模式锁，然后试图同时更新数据，则一个事务尝试将锁转换为排他锁（X 锁）。 共享模式到排他锁的转换必须等待一段时间，因为一个事务的排他锁与其他事务的共享模式锁不兼容；发生锁等待。 第二个事务试图获取排他锁（X 锁）以进行更新。 由于两个事务都要转换为排他锁（X 锁），并且每个事务都等待另一个事务释放共享模式锁，因此发生死锁。 若要避免这种潜在的死锁问题，请使用更新锁（U 锁）。 一次只有一个事务可以获得资源的更新锁（U 锁）。 如果事务修改资源，则更新锁（U 锁）转换为排他锁（X 锁）。

转自： http://blog.csdn.net/missmecn/archive/2008/10/06/3019798.aspx 相关文章: my sql 数据库锁 ORACLE里几种锁模式 推荐圈子: Pipboy 更多相关推荐 对 锁机制 的研究要具备两个条件： 1．数据量大 2．多个用户同时并发 如果缺少这两个条件，数据库不容易产生死锁问题。研究起来可能会事倍功半。如果这两个条件都有，但你还是按数据库缺省设置来处理数据，则会带来很多的问题，比如： 1）丢失更新 A,B两个用户读同一数据并进行修改,其中一个用户的修改结果破坏了另一个修改的结果 2）脏读 A用户修改了数据时,B用户也在读该数据,但A用户因为某些原因取消了对数据的修改,数据恢复原值,此时B得到的数据就与数据库内的数据产生了不一致 3）不可重复读 B用户读出该数据并修改,同时，A用户也在读取数据，此时A用户再读取数据时发现前后两次的值不一致 SQL SERVER 作为多用户数据库系统，以事务为单位，使用锁来实现并发控制。 SQL SERVER 使用“锁”确保事务完整性和数据一致性。 一、锁的概念 锁（LOCKING）是最常用的并发控制机构。是防止其他事务访问指定的资源控制、实现并发控制的一种主要手段。锁是事务对某个数据库中的资源（如表和记录）存取前，先向系统提出请求，封锁该资源，事务获得锁后，即取得对数据的控制权

表锁：MyISAM、MEMORY存储 引擎 ；行锁：InnoDB存储引擎；页锁：BDB存储引擎；默认情况下表锁和行锁都是自动获得的，不需要额外的命令；但是有时候用户需要明确的进行行锁或者进行事务的控制，以便确保整个事务的完整性，这样就需要用到事务控制和锁定语句来完成。 一、lock table 和 unlock table LOCK TABLE 用于锁定当前线程的表，UNLOCK TABLE 释放当前线程的任何锁定。当当前线程想要使用一个被别的线程锁定的表时会无法得到，只有等待别的线程将表释放并且当前线程获得到该表的锁定之后才能使用；另外还有一个值得注意的地方，当前线程执行另一个 LOCK TABLE 时，或与服务器的连接断开时，所有由当前线程锁定的表被隐式的解锁了。 相关语法如下： LOCK TABLES tbl_name [AS alias] { READ [LOCAL] | [LOW_PRIORITY] WRITE} [, ...] UNLOCK TABLES AS alias：起别名； READ [LOCAL]：READ表示对当前表进行只读锁定，当前会话和其它会话都只可读不可写（插入、更新等操作）；当有关键字LOCAL时，表示当前会话只读不可写，其它会话可读可写；另外，如果是InnoDB类型的表，READ 与 READ LOCAL是等效的，作用都是READ。 [LOW