数据库事务

3 月，跳不动了？>>> 这几天项目中遇到了数据库锁的问题，还在解决中，找到了一篇原理性的文章，分享一下。 在现代的多用户多任务系统中，必然会出现多个用户同时访问共享的某个对象，这个对象可能是表，行，或者内存结构，为了解决多个用户并发性访问带来的数据的安全性，完整性及一致性问题，必须要有一种机制，来使对这些共享资源的并发性访问串行化，oracle中的锁就可以提供这样的功能，当事务在对某个对象进行操作前，先向系统发出请求，对其加相应的锁，加锁后该事务就对该数据对象有了一定的控制权限，在该事务释放锁之前，其他的事务不能对此数据对象进行更新操作（可以做select动作，但select 利用的是undo中的前镜像数据了）. Oracle锁的分类 Oracle锁基本上可以分为二类 a：共享锁（share locks） 也称读锁，s锁 b：排它锁 (exclusive locks) 也称写锁，x锁 在数据库中有两种基本的锁类型：排它锁（Exclusive Locks，即X锁）和共享锁（Share Locks，即S锁）。当数据对象被加上排它锁时，其他的事务不能对它读取和修改。加了共享锁的数据对象可以被其他事务读取，但不能修改。数据库利用这两种基本的锁类型来对数据库的事务进行并发控制。 按锁保护的内容分类 oracle提供多粒度封锁机制，按保护对象来分，据此又可以分为 a：dml锁， data

事务并发产生的问题： 脏读：一个事务读取到了另外一个事务没有提交的数据 事务1：更新一条数据 ------------->事务2：读取事务1更新的记录 事务1：调用commit进行提交 ***此时事务2读取到的数据是保存在数据库内存中的数据，称为脏读。 ***读到的数据为脏数据 详细解释： 脏读就是指:当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时， 另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个 事务读到的这个数据是脏数据，依据脏数据所做的操作可能是不正确的。 不可重复读：在同一事务中，两次读取同一数据，得到内容不同 事务1：查询一条记录 -------------->事务2：更新事务1查询的记录 -------------->事务2：调用commit进行提交 事务1：再次查询上次的记录 ***此时事务1对同一数据查询了两次，可得到的内容不同，称为不可重复读 幻读：同一事务中，用同样的操作读取两次，得到的记录数不相同 事务1：查询表中所有记录 -------------->事务2：插入一条记录 -------------->事务2：调用commit进行提交 事务1：再次查询表中所有记录 ***此时事务1两次查询到的记录是不一样的，称为幻读 详细解释： 幻读是指当事务不是独立执行时发生的一种现象

　　”读现象“是多个事务并发执行时，在读取数据方面可能碰到的状况。先了解它们有助于理解各隔离级别的含义。其中包括脏读、不可重复读和幻读。 　　脏读 　　脏读又称无效数据的读出，是指在数据库访问中事务T1将某一个值修改，然后事务T2读取该值，此后T1因为某种原因撤销对该值的修改，这就导致了T2所读取到的数据是无效的 　　脏读就是指当一个事务正在方位数据，并且对数据进行了修改，而这种修改还没有提交到数据库中。这时，另一个事务也访问这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务督导的这个数据是脏数据，依据脏数据所做的操作可能是不正确的。 　　 　　不可重复读 　　是指在数据库访问中一个事务范围内两个相同的查询却返回了不同数据。这是由于查询时系统中其他事务修改的提交而引起的。比如事务T1读取了某一数据，事务T2读取并修改了该数据。T1为了对读取值进行检验而再次读取该数据，便得到了不同的结果。 　　一种更易理解的说法是：在一个事务内，多次读同一个数据。在这个事务还没有结束时，另一个事务也访问该同一数据。那么，在第一个事务的两次读数据之间。由于第二个事务的修改，那么第一个事务督导的数据可能不一样，这样就发生了在一个是屋内两次读到的数据是不一样的，因此称为不可重复读，即原始数据不可重复度。 　　幻读 　　幻读是指当事务不是独立执行时发生的一种现象

事务处理之父Jim Gray对事务隔离性的定义： Isolation: Concurrently executing transactions see the stored information as if they were running serially (one after another). 事务的隔离级别从低到高有： Read Uncommitted ：最低的隔离级别，什么都不需要做，一个事务可以读到另一个事务未提交的结果。所有的并发事务问题都会发生。 Read Committed ：只有在事务提交后，其更新结果才会被其他事务看见。可以解决脏读问题。 Repeated Read ：在一个事务中，对于同一份数据的读取结果总是相同的，无论是否有其他事务对这份数据进行操作，以及这个事务是否提交。可以解决脏读、不可重复读。 Serialization ：事务串行化执行，隔离级别最高，牺牲了系统的并发性。可以解决并发事务的所有问题。 通常，在工程实践中，为了性能的考虑会对隔离性进行折中。 其中只有serialization实现隔离性所有要求，在真正实现事务的隔离性。 但考虑到实践，为了性能，数据库厂商做出了这方面的妥协，让使用者可以选择隔离的级别。 不同的隔离级别可以解决不同阶段的问题，是层层递进，逐渐增强的关系。 隔离性为了解决的问题主要有三个

网络上关于这方面的博文有些偏理论，有些通篇代码，都不能深入浅出。本文用图文并茂的方式，配上行云流水般的代码，非要摆清楚这个问题。相关代码已提交至码云（点击 这里 下载）。 事务是现代关系型数据库的核心之一。在多个事务并发操作数据库（多线程、网络并发等）的时候，如果没有有效的避免机制，就会出现以下几种问题： 第一类丢失更新（Lost Update） 在完全未隔离事务的情况下，两个事务更新同一条数据资源，某一事务完成，另一事务异常终止，回滚造成第一个完成的更新也同时丢失 。这个问题现代关系型数据库已经不会发生，就不在这里占用篇幅，有兴趣的可以自行百度。 脏读（Dirty Read） A事务执行过程中，B事务读取了A事务的修改。但是由于某些原因，A事务可能没有完成提交，发生RollBack了操作，则B事务所读取的数据就会是不正确的。这个未提交数据就是脏读（Dirty Read）。脏读产生的流程如下： 可以用EF Core模拟此过程： class TestReadUncommitted :TestBase { private AutoResetEvent _autoResetEvent; [Test] public void ReadUncommitted() { using (var context = _autofacServiceProvider.GetService

2017年6月5日，天气——雨。 前两天整理之前的学习笔记时，发现对事务并发产生的问题——脏读、幻读、不可重复读和丢失更新这些概念有点模糊，于是又重新温习了一遍，现在把自己的一些理解归纳整理如下，方便大家学习。 锁就是防止其他事务访问指定资源的手段。锁是实现并发控制的主要方法，是多个用户能够同时操纵同一个 数据库 中的数据而不发生数据不一致现象的重要保障。 一般来说，锁可以防止脏读、不可重复读和幻读。 1. 脏读(Dirty Read) ——一个事务读取到了另外一个事务没有提交的数据。 详细解释：当一个事务正在访问数据并且对数据进行了修改，而这种修改还没有提交到数据库中，这时另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是脏数据，依据脏数据所做的操作可能是不正确的。 事务T1：更新一条数据 -->事务T2：读取事务T1更新的记录 事务T1：调用commit进行提交 此时事务T2读取到的数据是保存在数据库内存中的数据，称为脏数据，这个过程称为脏读。 脏读发生在一个事务A读取了被另一个事务B修改，但是还未提交的数据。假如B回退，则事务A读取的是无效的数据。这跟不可重复读类似，但是第二个事务不需要执行提交。 解决脏读问题：修改时加排他锁，直到事务提交后才释放，读取时加共享锁，读取完释放事务1读取数据时加上共享锁后

关系型数据库都具有一套事务级别，以前的开发和学习过程我很少关注过这个概念，今天搜集了一些资料，在 结合spring声明式事务学习的同时，总结一下数据库的事务级别与操作。 READ-UNCOMMITTED: 未提交读 会出现脏读、不可重复读、幻读 ( 隔离级别最低，并发性能高 ) READ-COMMITTED: 提交读 会出现不可重复读、幻读问题（锁定正在读取的行） REPEATABLE-READ: 可重复读 会出幻读（锁定所读取的所有行） SERIALIZABLE: 序列化 保证所有的情况不会发生（锁表） 详细说明： 未提交读 ——这通常称为 'dirty read'：non-locking SELECT 的执行使我们不会看到一个记录的可能更早的版本； 因而在这个隔离级别下是非 'consistent' reads；这级隔离级别的运作如同 READ COMMITTED。处于这个隔离级的 事务可以读到其他事务还没有提交的数据。如果这个事务使用其他事务未提交的变化作为计算的基础，然后那些未 提交的变化被他们的父事务撤销，则会导致误差。 提交读 ——在一个事务中已经COMMIT的数据可以在其他事务中看到。如果这个事务频繁提交的话，其他的大的查询 事务中可能会得到多个不同的结果。 可重复读 ——这是 InnoDB 默认的事务隔离级。在一个事务中所有读都是连续的。 序列化 —

一、事务隔离级别 　　在数据库系统中， 隔离 是定义一个操作对数据所做的改变如何/何时对其它的 并行 操作可见。　　 　　在数据库操作中， 为了有效保证并发读取数据的正确性 ，提出的事务隔离级别。 　　事务隔离级别：一个事务对数据库的修改与并行的另一个事务的隔离程度。　　 二、事务并发执行涉及到的问题 　　数据库是要被广大客户所共享访问的，那么在数据库操作过程中很可能出现以下几种不确定情况： 　　脏读(Drity Read)：某个事务已更新一份数据还未提交，另一个事务在此时读取了同一份数据，由于某些原因，前一个事务RollBack了操作，则后一个事务所读取到的数据就会是不正确的。 　　不可重复读(Non-repeatable read):在一个事务的两次相同查询中数据不一致，这可能是两次查询过程中间插入了另一个事务更新了原有的数据。也可以说：事务T1读取某一数据后还未提交，事务T2对其做了修改，当事务T1再次读该数据时得到与前一次不同的值。 　　幻读(Phantom Read):在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的。 三、解决方法--4类事务隔离级别 　　SQL标准定义了4类隔离级别，包括了一些具体规则，用来限定事务内外的哪些改变是可见的

Mysql相关 mysql增删改查 我们需要修改数据表名或者修改数据表字段时，就需要使用到Mysql Alter命令 删除，添加或修改表字段 alter table student drop register_date; #从student表删除register_date alter table student add phone int(11) not null; #添加phone字段 修改字段类型及名称 如果需要修改字段类型及名称，你可以在alter命令中使用Modify或change 例如：把字段c的类型从char(1)改为char(10)，可以执行以下命令: alter table testalter_tbl modigy c char(10); 使用change子句，语法有很大的不同。在change关键字之后，紧跟着的是你要修改的字段名，然后指定新字段名及类型。 alter table testalter_tbl change i j BIGINT; alter table testalter_tbl change j j int; alter table对null值和默认值的影响 当你修改字段时，你可以指定是否包含只或者是否设置默认值 以下实例，指定字段j为not null且默认值为100 alter table testalter_tbl modify j

我们知道，在关系数据库标准中有四个事务隔离级别： 未提交读(Read Uncommitted)：允许脏读，也就是可能读取到其他会话中未提交事务修改的数据 提交读(Read Committed)：只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别 可重复读(Repeated Read)：可重复读。在同一个事务内的查询都是事务开始时刻一致的，InnoDB默认级别。在SQL标准中，该隔离级别消除了不可重复读，但是还存在幻象读 串行读(Serializable)：完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞 查看InnoDB系统级别的事务隔离级别： 以下为引用的内容： mysql> SELECT @@global.tx_isolation; +-----------------------+ | @@global.tx_isolation | +-----------------------+ | REPEATABLE-READ　　　| +-----------------------+ 1 row in set (0.00 sec) 查看InnoDB会话级别的事务隔离级别： 以下为引用的内容： mysql> SELECT @@tx_isolation; +-----------------+ | @@tx_isolation　| +-------------