事务隔离级别

一、含义 事务：一条或多条sql语句组成一个执行单位，一组sql语句要么都执行要么都不执行 二、特点（ACID） A 原子性：一个事务是不可再分割的整体，要么都执行要么都不执行 C 一致性：一个事务可以使数据从一个一致状态切换到另外一个一致的状态 I 隔离性：一个事务不受其他事务的干扰，多个事务互相隔离的 D 持久性：一个事务一旦提交了，则永久的持久化到本地 三、事务的使用步骤 ★ 了解： 隐式（自动）事务：没有明显的开启和结束，本身就是一条事务可以自动提交，比如insert、update、delete 显式事务：具有明显的开启和结束 使用显式事务： ①开启事务 set autocommit=0; start transaction;#可以省略 ②编写一组逻辑sql语句 注意：sql语句支持的是insert、update、delete 设置回滚点： savepoint 回滚点名; ③结束事务 提交：commit; 回滚：rollback; 回滚到指定的地方：rollback to 回滚点名; 四、并发事务 1、事务的并发问题是如何发生的？ 多个事务 同时 操作 同一个数据库的相同数据时 2、并发问题都有哪些？ 脏读：一个事务读取了其他事务还没有提交的数据，读到的是其他事务“更新”的数据 不可重复读：一个事务多次读取，结果不一样 幻读：一个事务读取了其他事务还没有提交的数据

１.@Transactional　　当标于类前时, 标示类中所有方法都进行事物处理 ２.@Transactional(propagation=Propagation.NOT_SUPPORTED) 　　当类中某些方法不需要事物时 ３.@Transactional(propagation=Propagation.REQUIRED) 　　如果有事务, 那么加入事务, 没有的话新建一个(默认情况下)４.@Transactional(propagation=Propagation.REQUIRES_NEW) 　　不管是否存在事务,都创建一个新的事务,原来的挂起,新的执行完毕,继续执行老的事务５.@Transactional(propagation=Propagation.MANDATORY) 　　必须在一个已有的事务中执行,否则抛出异常６.@Transactional(propagation=Propagation.NEVER) 　　在一个没有的事务中执行,否则抛出异常(与Propagation.MANDATORY相反)７.@Transactional(propagation=Propagation.SUPPORTS) 　　如果其他bean调用这个方法,在其他bean中声明事务,那就用事务.如果其他bean没有声明事务,那就不用事务.事务隔离级别:@Transactional

1:创建时；【column】不能使用关键字 2：多对一，一对多：【name】与【classs】与【column】看准 进入命令行，windows cmd，连接： mysql -u 用户名 -p密码 -h 服务器IP地址 -P 服务器端MySQL端口号 -D 数据库名 SQL的分类： 数据查询语言DQL（查询） select 数据操纵语言DML（对数据增删改） insert,delete,update 数据定义语言DDL（对表结构增删改） create,drp,alter 事务控制语言TCL（事务提交回滚） commit,rollback 数据控制语言DCL（创建用户授权） grant,revoke show variables like '%char%'; --查看字符集 select version(); -- 查看数据库版本 CREATE DATABASE cs; -- 创建数据库 DROP DATABASE cs; -- 删除数据库 USE cs; -- 使用这个数据库 SELECT DATABASE(); -- 当前使用的数据库 source ***.sql; -- 导入sql文件，运行 SHOW TABLES; -- 查看数据库下的表 DESC 表名; -- 查看表结构 ALTER TABLE form1 DROP COLUMN 列名; -- 删除指定字段 ALTER

一、基本介绍 1、概念 如果一个包含多个步骤的业务操作，被事务管理，那么这些操作要么同时成功，要么同时失败； 2、操作 ①开启事务：start transaction; ②回滚：rollback; ③提交：commit; 案例： 3、MySql数据库中事务默认自动提交 事务自动提交： 一条DML（增删改）语句会自动提交一次事务； 事务手动提交： 手动开启事务（start transaction），需要手动提交（commit）； 修改事务的默认提交方式： -- 查看默认的提交方式 select @@autocommit; -- 1代表自动提交 0代表手动提交 -- 修改默认的提交方式 set @@autocommit = 0; 二、事务的四大特征（常见面试题） 1、原子性： 是不可分割的最小操作单位，要么同时成功，要么同时失败； 2、持久性： 当事务提交或回滚后，数据库会持久化地保存数据； 3、隔离性： 多个事物之间相互独立；（实际上，多个事物之间会产生影响，需要进行手动隔离（类似Java多线程里面，需要锁机制）） 4、一致性： 事务操作前后，数据总量不变； 三、事务的隔离级别（了解） 1、概念： 多个事务之间是相互独立的，但是多个事务同时操作同一批数据则会引发一些问题，设置不同的隔离级别就可以解决这些问题； 2、存在问题 ①脏读：一个事务读取到另一个事务中没有提交的数据；

背景 最近要做一个批跑服务, 基本逻辑就是定时扫描数据库的记录, 有满足条件的就进行处理(一条记录代表一个任务,以下任务与记录含义相同). 要求支持多机部署批跑服务. 批跑支持多机部署实现方案 要实现多机部署, 只要保证每个批跑服务实例每次只获取一条记录, 处理完再获取下一条即可. 其中最种要的是避免不同的实例获取到同一条记录,即所谓抢任务. 先看表结构设计: create database if not exists ae; create table ae.task ( id int primary key, status int); -- status为0说明任务可处理,其它不可处理 以上是简化的表结构,但足以说明本文试图说明的问题. 要避免抢任务, oracle的做法, 直接 update ae.task set status=1 where status=0 and rownum = 1 returning id 即可. mysql的要啰嗦一点: select id from ae.task where status=0; -- 得到ID update ae.task where id = ${id} and status=0; 这两个sql,第一个sql用于获取符合条件的任务, 第二个sql用户将任务锁定. 在并发的场景下,

事务的定义 事务 ：数据库操作的最小工作单元，是作为单个逻辑工作单元执行的一系列操作; 事务是一组不可再分割的操作集合（工作逻辑单元）。 典型事务使用场景 ：转账 update user_account set balance = balance - 1000 where userID = 3; update user_account set balance = balance + 1000 where userID = 1; MySQL 开启事务 ： /* BEGIN / START TRANSACTION --手工 COMMIT / ROLLBACK --事务提交或回滚 SET SESSION autocommit = ON/OFF --设定会话级别事务是否自动开启 */ MySQL 默认是开启事务的，通过 SHOW VARIABLES like 'autocommit'; 可以查看 MySQL 的事务开启情况。 在 autocommit = ON（自动提交事务）的情况下，可以执行 BEGIN; 或者 START TRANSACTION; 命令，改为手动提交事务，执行完 SQL 语句后，需要通过 COMMIT 命令提交事务，或者通过 ROLLBACK 命令回滚事务。 在 autocommit = OFF（手动提交事务）的情况下，执行完 SQL 语句后，需要通过 COMMIT

写在前面 这篇文章是在网络上看到其他作者的优秀博文，自己消化理解之后所做的记录。文章基于 MySQL 中的 InnoDB 存储引擎。 原博文地址： 点我 锁 锁知识概览 我们先看一张锁的概览图，方便后续的讲述： 我们的程序在一般情况下还是可以跑得好好的。因为这些锁数据库 隐式 帮我们加了；只在某些特定的场景下，才需要程序员手动加锁。 在执行「查询语句」 SELECT 前，会自动给涉及的所有表加「表级锁」中的 读锁 ；在执行「更新操作」 UPDATE、DELETE、INSERT 前，会自动给涉及的表加「表级锁」中的 写锁 对于 InnoDB ,且 使用了索引 的「更新操作」 UPDATE、DELETE、INSERT 语句；这时 InnoDB 会将「表锁」转换成「行锁」，也就是会自动给涉及数据集加「行级锁」中的 排他锁（X) 注意 ：InnoDB 只有通过「索引」检索数据才使用「行级锁」，否则，InnoDB将使用表锁；也就是说，InnoDB 的 行锁基于索引 。 一种特殊情况 如果我们对表中的某列加的是「普通索引」，那也就意味着： 索引列属性可能重复 。 对于普通索引，当 重复率高 时，MySQL 不会把这个普通索引当做索引，即会造成一个没有索引的SQL，从而 形成表锁 。 锁的分类 从上图中，以锁的粒度出发，我们可以看到锁分为「表级锁」和「行级锁」 『表锁』：开销小，加锁快

1.redis的事务是基于队列实现的 mysql的事务是基于事务日志和锁机制实现的 redis是乐观锁机制 redis与mysql事务的区别： 　　mysql事务是一开始就在内存里面执行了，只是还没有提交。 　　而redis是把任务放在队列里，还没有执行。只有exec的时候，才是真正的执行了。 开启事务 multi #进入事务 command1 #要执行的命令 command2 #要执行的命令 command3 #要执行的命令 command4 #要执行的命令 exec #执行 discard #取消执行 4条语句作为一个组，并没有真正执行，而是被放入同一队列中。 如果，这时执行discard，会直接丢弃队列中所有的命令，而不是做回滚。 当执行exec时，队列中所有操作，要么全成功要么全失败 redis事务还有监听命令 watch key 乐观锁悲观锁 乐观锁：顾名思义很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量 悲观锁：顾名思义很悲观，每次去拿数据的时候都认为别人修改，所以每次在拿数据的时候都会上锁，这样如果中间有人想拿数据就会一直阻塞除非锁被释放获取到锁。传统的关系型数据库里，用到了很多种这种锁机制，比如行锁，表锁，写锁等 2

并发大了，经常出现这个提示： /”应用程序中的服务器错误。 事务(进程 ID 133)与另一个进程被死锁在 锁 资源上，并且已被选作死锁牺牲品。请重新运行该事务。 说明: 执行当前 Web 请求期间，出现未经处理的异常。请检查堆栈跟踪信息，以了解有关该错误以及代码中导致错误的出处的详细信息。 异常详细信息: System.Data.SqlClient.SqlException: 事务(进程 ID 133)与另一个进程被死锁在 锁 资源上，并且已被选作死锁牺牲品。请重新运行该事务。 源错误: 执行当前 Web 请求期间生成了未经处理的异常。可以使用下面的异常堆栈跟踪信息确定有关异常原因和发生位置的信息。 估计就是抢锁造成的，查看了这篇文章终于找到了解决方案： SELECT COUNT(*) FROM Example WITH(NOLOCK) ，加上 WITH(NOLOCK) 就可以了 原文地址 NOLOCK NOLOCK在概念上类似于READ UNCOMMITTED隔离级别，并且只针对于SELECT查询语句，它不会获取表的共享锁，换句话说不会阻止排它锁来更新数据行。当我们对表进行NOLOCK有什么好处呢？它能够提高并发性能，因为此时SQL Server数据库引擎不必去维护共享锁，由于不会对正在读取的表获取共享锁，所以可能导致未提交的事务也会被读取，所以此时缺点显而易见将导致脏读

事务是逻辑上的一组操作，要么都执行，要么都不执行。 事务最经典的、经常被拿出来说的例子就是转账了。假如小花要给小白转账1000元，这个转账会涉及到两个关键操作就是：将小花的余额-1000，将小白的余额+1000。但是万一在这两个操作之间突然出现了错误，比如银行系统突然断电，或突然宕机崩溃，都可能会导致小花的余额-1000之后，小白的余额却没有+1000，这样小花和小白就都不开心了。事务就是为了保证这两个关键操作要么都成功，要么都要失败的一个机制，都成功也就完成了转账，都失败也不会造成小花的损失。 事务的特性 事务是有四个特性（ACID）的，分别是原子性、一致性、隔离性和持久性。 原子性（Atomity）： 事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用。 一致性（Consistency）： 执行事务的前后，数据保持一致。 隔离性（Isolation）： 并发访问数据库时，一个用户的事务不能被其他事务所干扰，各个并发事务对于数据库来说都是独立的。 持久性（Durable）： 一个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。 并发事务带来的问题 在典型的应用程序中，如果是多个事务并发运行，经常会出现多个事务操作相同的数据来完成各自的任务（多个用户对统一数据进行操作）的场景。 虽然并发是必须的