mysql事务

mysql(一)事务管理

邮差的信 提交于 2019-12-10 21:20:37
事务管理 mysql默认事务管理级别 Oracle默认事务管理级别 名词解释 mysql默认事务管理级别 mysql默认的事务处理级别是’REPEATABLE-READ’,也就是可重复读 1.查看当前会话隔离级别 select @@tx_isolation; 2.查看系统当前隔离级别 select @@global.tx_isolation; 3.设置当前会话隔离级别 set session transaction isolatin level repeatable read; 4.设置系统当前隔离级别 set global transaction isolation level repeatable read; Oracle默认事务管理级别 oracle数据库支持READ COMMITTED 和 SERIALIZABLE这两种事务隔离级别。 默认系统事务隔离级别是READ COMMITTED,也就是读已提交 名词解释 1、脏读:事务A读取了事务B更新的数据,然后B回滚操作,那么A读取到的数据是脏数据 2、不可重复读:事务 A 多次读取同一数据,事务 B 在事务A多次读取的过程中,对数据作了更新并提交,导致事务A多次读取同一数据时,结果 不一致。 3、幻读:系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级,但是系统管理员B就在这个时候插入了一条具体分数的记录

数据库

天大地大妈咪最大 提交于 2019-12-10 20:06:50
update 表名 set 值=新值 where 列名 in (select 列名 from 表名 where 筛选条件) 删除 delete from 表名 where 筛选条件 插入指定列名 insert [into] 表名(列名1,列名2.。。)values(列值1,列值2.。。); 不指定字段 insert 表名 values (‘1002’,‘李璐0’,null) 插入多行 insert 表名 (列名1,列名2)values (列值1,列值2),(列值1,列值2); INSERT student (id,name,zz) SELECT id,name,zz from student; sql语句基本格式: select<输出字段>from 表1,表2{。。。} where <表1,字段名1><链接谓词><表2.字段2> group by 字·段名 having 条件 order by 字段名 sac/desc limit n,m select distinct 字段列表 或 函数 或 表达式 as 别名 from 表名 as 别名 where 条件 group by 字段名 Having 条件表达式 order by 字段名 asc,desc limit n,m; E-R图:1:1 1:多 多:多 数据库设计模型 概念模型:对客观事物的描述 逻辑模型:(层次模型、网状模型

mysql可重复读

耗尽温柔 提交于 2019-12-10 19:52:42
mysql innodb的默认隔离级别是可重复读,之前理解有些偏差,查阅一些资料后总结出几点 首先有两个概念: 一致性视图:当一个事务开启时,innodb会生成一个视图,这个视图是逻辑视图,通过undo log和row tranzaction id控制实现。在该事务的任何时间点,一致性视图中的数据都是一样的 当前读:当innodb执行dml时,使用的是当前读,并且要先获得行锁(没有索引时为表锁) 到底什么数据(修改)是可见的? 1.普通的select:一致性视图+本事务中做的修改 2.dml和select …for update或者其它带锁的查询:一致性视图+本事务中做的修改+其它已提交事务的修改。也就是当前读,其实很好理解,既然用到了锁,同步数据状态也是应该的。 来源: CSDN 作者: weixin_39913976 链接: https://blog.csdn.net/weixin_39913976/article/details/103480972

mysql 幻读的详解、实例及解决办法

荒凉一梦 提交于 2019-12-10 16:38:01
事务隔离级别(tx_isolation) mysql 有四级事务隔离级别 每个级别都有字符或数字编号 读未提交 READ-UNCOMMITTED | 0:存在脏读,不可重复读,幻读的问题 读已提交 READ-COMMITTED | 1:解决脏读的问题,存在不可重复读,幻读的问题 可重复读 REPEATABLE-READ | 2:解决脏读,不可重复读的问题,存在幻读的问题,默认隔离级别,使用 MMVC机制 实现可重复读 序列化 SERIALIZABLE | 3:解决脏读,不可重复读,幻读,可保证事务安全,但完全串行执行,性能最低 我们可以通过以下命令 查看/设置 全局/会话 的事务隔离级别 mysql> SELECT @@global.tx_isolation, @@tx_isolation; +-----------------------+------------------+ | @@global.tx_isolation | @@tx_isolation | +-----------------------+------------------+ | REPEATABLE-READ | READ-UNCOMMITTED | +-----------------------+------------------+ 1 row in set (0.00 sec) #

jee第5章 --- Spring的事务管理

六眼飞鱼酱① 提交于 2019-12-10 11:11:30
目录 5.1 Spring事务管理概述 什么是Spring的事务管理 5.1.1 事务管理的核心接口(PlatformTransactionManager接口) 5.1.2 事务管理的方式 5.2 声明式事务管理 如何实现Spring的声明式事务管理 5.2.1 基于XML方式的声明式事务 5.2.2 基于Annotation方式的声明式事务 5.1 Spring事务管理概述 什么是Spring的事务管理 在实际开发中, 操作数据库时都会涉及到事务管理问题 ,为此Spring提供了专门用于事务处理的API。 Spring的事务管理简化了传统的事务管理流程,减少了开发者的工作量 。 5.1.1 事务管理的核心接口(PlatformTransactionManager接口) JAR包 spring-tx-4.3.6.RELEASE(Spring提供的用于事务管理的依赖包) JAR包下的org.springframework.transaction包的三个接口文件 PlatformTransactionManager TransactionDefinition TransactionStatus 关于 PlatformTransactionManager接口 ,Spring提供的平台事务管理器,它提供了操作事务的三个方法: TransactionStatus getTransaction

H2介绍 – Java嵌入式数据库

丶灬走出姿态 提交于 2019-12-09 19:59:04
H2是一个用Java开发的嵌入式数据库,这里指的嵌入式不是手持设备之类的,而是H2数据库作为一个类库,直接嵌入到上层的应用程序中,与应用运行在同一个进程中。 最大的优势在于可以同应用程序打包在一起发布,对于客户端应用来说,非常方便。比如说腾讯QQ或者Mozilla Firefox,用户不可能为了用个软件还得在自己机器上装个MySQL?SQL Server?上述软件就使用嵌入式数据库SQLite来进行客户端本地存储。H2的定位和SQLite一样,属于嵌入式数据库。(H2也可以用在Android上哦) 另一个优势是,写代码时需要写单元测试,与数据库操作相关的功能单元测试都比较不好做,因为有一个环境的问题,而采用H2来进行就要比MySQL要方便的多,首先是启动速度快,而且可以关闭持久化功能,表只存在内存中,每一个用例执行完自动还原到纯净环境。 现在很多开源产品的发布版中所附的测试用例,都是用的H2,目前大家都是把它用作测试。我感觉它的另一个用处是作为内存缓存,NoSQL的一个补充,当某些场景下数据模型必须为关系型,可以拿它当Memcached使,作为后端MySQL/Oracle的一个缓冲层,缓存一些不经常变化但需要频繁访问的数据,比如字典表、权限表。 H2使用非常简单,使用URL: jdbc:h2:~/test 来建立JDBC连接,就会自动创建一个test.h2.db文件和一个test

记录次spring的事务问题

孤人 提交于 2019-12-09 18:12:36
1.问题出现 1.代码如下: @Override @Transactional public void addUser2 ( String name , String password ) { userNoteMapper . addUser ( name , password ) ; System . out . println ( 1 / 0 ) ; } 2.现象是: 事务无论怎么样,都不进行事务的回滚,数据正常插入 3.问题排查: 1.首先进行方法的模拟,在dao测试,service测试,controller测试,接口测试,添加事务对插入无任何影响。排除在外??? 2.检查是否是类方法中的调用,只是单一的调用。排除在外??? 3.检查是否是数据库表的设计,mysql中引擎是否支持事务。在mysql中,innerdb是支持事务,而myisam不支持事务。我的错误正是数据表的引擎为myisam。 2.模拟spring事务的各种现象 1.李子 @Override @Transactional public void addUser2 ( String name , String password ) { userNoteMapper . addUser ( name , password ) ; System . out . println ( 1 / 0 ) ; //此处抛出异常

数据库事务的学习笔记

烂漫一生 提交于 2019-12-09 14:34:37
对事务本身的理解 1.事务是一组原子性的SQL查询,对于事务内的查询要么完全成功,要么完全失败。 2.mysql默认的事务是自动提交的,即autocommit=true,也就是说一个SQL查询即是一个事务。 3.对于多条语句,通过start transaction;和commit(rollback)进行配合,将多条语句包装为一个更大的事务单元。 4.如果设置autocommit=false,那么语句将不会被提交,直到使用rollback,或者commit。 5.事务的特性ACID(原子性,一致性,隔离性,持久性) 原子性:要求一个事务不可分割,里面的语句要么全部成功,要么全部失败,不会看到中间状态。 一致性:个人感觉是数据库数据本身和数据之间的约束关系在事务前后是不会变的。 隔离性:即一个事务在提交之前,他对记录的修改对其他事务不可见。为了防止过多的锁,MYSQL通过MVCC实现。 持久性:即事务对记录的修改,在提交时候会被永久的保存到磁盘上。MYSQL为了提高事务效率,存储引擎在修改数据时通常只修改内存数据,同时将修改操作记录到“事务日志”中,再异步的刷回磁盘。 对事务隔离级别的理解 Read Uncommited 未提交读,数据库级别的最低层次,事务会读到其他事务未提交的数据。这种事务级别只保证磁盘不出问题。产生的问题即脏读。 如图: 左侧事务中对age

Innodb中的事务隔离级别和锁的关系

元气小坏坏 提交于 2019-12-09 00:08:07
前言: 我们都知道事务的几种性质,数据库为了维护这些性质,尤其是一致性和隔离性,一般使用加锁这种方式。同时数据库又是个高并发的应用,同一时间会有大量的并发访问,如果加锁过度,会极大的降低并发处理能力。所以对于加锁的处理,可以说就是数据库对于事务处理的精髓所在。这里通过分析MySQL中InnoDB引擎的加锁机制,来抛砖引玉,让读者更好的理解,在事务处理中数据库到底做了什么。 #一次封锁or两段锁? 因为有大量的并发访问,为了预防死锁,一般应用中推荐使用一次封锁法,就是在方法的开始阶段,已经预先知道会用到哪些数据,然后全部锁住,在方法运行之后,再全部解锁。这种方式可以有效的避免循环死锁,但在数据库中却不适用,因为在事务开始阶段,数据库并不知道会用到哪些数据。 数据库遵循的是两段锁协议,将事务分成两个阶段,加锁阶段和解锁阶段(所以叫两段锁) 加锁阶段:在该阶段可以进行加锁操作。在对任何数据进行读操作之前要申请并获得S锁(共享锁,其它事务可以继续加共享锁,但不能加排它锁),在进行写操作之前要申请并获得X锁(排它锁,其它事务不能再获得任何锁)。加锁不成功,则事务进入等待状态,直到加锁成功才继续执行。 解锁阶段:当事务释放了一个封锁以后,事务进入解锁阶段,在该阶段只能进行解锁操作不能再进行加锁操作。 事务 加锁/解锁处理 begin; insert into test .....

gtid

拜拜、爱过 提交于 2019-12-08 17:25:45
gtid知识: 1、gtid配置 MySQL通过全局变量gtid_mode控制开启/关闭GTID模式。但是gtid_mode是只读的,可添加到配置文件中,然后重启mysqld来开启GTID模式。相关配置项如下: gtid-mode = ON enforce_gtid_consistency = 1 log-slave-updates = 1 log-bin = mysql-bin log-bin-index = mysql-bin.index 2、查看配置 > show global variables like 'gtid_%'\G; *************************** 1. row *************************** Variable_name: gtid_executed Value: 5a1a41db-9f15-11e9-a991-e4434b210720:1-2, 5aa95098-9f15-11e9-98f3-e4434b5a47f8:1-429, 5bcba8f5-9f15-11e9-9b14-e4434b210748:1-6319147104, 5d2b585f-9f15-11e9-a58d-e4434b2106e8:1-1373519, 62cdce4f-9f15-11e9-9f0d-e4434b21b430:1-2,