2014年9月

Mysql事务以及隔离级别

数据库事务概念

数据库事务必须同时满足 4 个特性:原子性(Atomic)、一致性(Consistency)、隔离性(Isolation)和持久性(Durabiliy),简称为ACID。下面是对每个特性的说明。

  • 原子性:表示组成一个事务的多个数据库操作要么全部成功、要么全部失败。
  • 一致性:事务操作成功后,数据库所处的状态和它的业务规则是一致的,即数据不会被破坏。如从A账户转账100元到B账户,不管操作成功与否,A和B的存款总额是不变的。
  • 隔离性:在并发数据操作时,不同的事务拥有各自的数据空间,它们的操作不会对对方产生干扰。准确地说,并非要求做到完全无干扰,数据库规定了多种事务隔离级别,不同隔离级别对应不同的干扰程度,隔离级别越高,数据一致性越好,但并发性越弱。
  • 持久性:一旦事务提交成功后,事务中所有的数据操作都必须被持久化到数据库中,即使提交事务后,数据库马上崩溃,在数据库重启时,也必须能保证能够通过某种机制恢复数据。

其实这四个特性,原子性是最终目的。

 

数据并发的问题

一个数据库可能拥有多个访问客户端,这些客户端都可以并发方式访问数据库。数据库中的相同数据可能同时被多个事务访问,如果没有采取必要的隔离措施,就会导致各种并发问题,破坏数据的完整性。这些问题可以归结为5类,包括3类数据读问题( 脏读、 不可重复读和 幻象读)以及2类数据更新问题( 第一类丢失更新和 第二类丢失更新)。下面,我们分别通过实例讲解引发问题的场景。

脏读(dirty read)

A事务读取B事务尚未提交的更改数据,并在这个数据的基础上操作。如果恰巧B事务回滚,那么A事务读到的数据根本是不被承认的。来看取款事务和转账事务并发时引发的脏读场景:

15150645_B8Se

 

在这个场景中,B希望取款500元而后又撤销了动作,而A往相同的账户中转账100元,就因为A事务读取了B事务尚未提交的数据,因而造成账户白白丢失了500元。在Oracle数据库中,不会发生脏读的情况。

不可重复读(unrepeatable read)

不可重复读是指 A事务读取了B事务已经提交的更改数据。假设A在取款事务的过程中,B往该账户转账100元,A两次读取账户的余额发生不一致:

15150645_B8Se

 

在同一事务中,T4时间点和T7时间点读取账户存款余额不一样。

幻象读(phantom read)

A事务读取B事务提交的新增数据,这时A事务将出现幻象读的问题。幻象读一般发生在计算统计数据的事务中,举一个例子,假设银行系统在同一个事务中,两次统计存款账户的总金额,在两次统计过程中,刚好新增了一个存款账户,并存入100元,这时,两次统计的总金额将不一致:

15150645_d6yw

 

如果新增数据刚好满足事务的查询条件,这个新数据就进入了事务的视野,因而产生了两个统计不一致的情况。

幻象读和不可重复读是两个容易混淆的概念,前者是指读到了其他已经提交事务的新增数据,而后者是指读到了已经提交事务的更改数据(更改或删除),为了避免这两种情况,采取的对策是不同的,防止读取到更改数据,只需要对操作的数据添加行级锁,阻止操作中的数据发生变化,而防止读取到新增数据,则往往需要添加表级锁——将整个表锁定,防止新增数据(Oracle使用多版本数据的方式实现)。

第一类丢失更新

A事务撤销时,把已经提交的B事务的更新数据覆盖了。这种错误可能造成很严重的问题,通过下面的账户取款转账就可以看出来:

15150645_d6yw

A事务在撤销时,“不小心”将B事务已经转入账户的金额给抹去了。

第二类丢失更新

A事务覆盖B事务已经提交的数据,造成B事务所做操作丢失:

15150645_d6yw

 

上面的例子里由于支票转账事务覆盖了取款事务对存款余额所做的更新,导致银行最后损失了100元,相反如果转账事务先提交,那么用户账户将损失100元。

四种隔离级别

尽管数据库为用户提供了锁的DML操作方式,但直接使用锁管理是非常麻烦的,因此数据库为用户提供了自动锁机制。只要用户指定会话的事务隔离级别,数据库就会分析事务中的SQL语句,然后自动为事务操作的数据资源添加上适合的锁。此外数据库还会维护这些锁,当一个资源上的锁数目太多时,自动进行锁升级以提高系统的运行性能,而这一过程对用户来说完全是透明的。
ANSI/ISO SQL 92标准定义了4个等级的事务隔离级别:

15150645_d6yw

 

事务的隔离级别和数据库并发性是对立的,两者此增彼长。一般来说,使用READ UNCOMMITED隔离级别的数据库拥有最高的并发性和吞吐量,而使用SERIALIZABLE隔离级别的数据库并发性最低。

Mysql的默认隔离级别时Repeatable Read,即可重复读。

 

Mysql中使用Insert批量更新数据

我们知道当插入多条数据的时候insert支持多条语句:

INSERT INTO t_member (id, name, email) VALUES
    (1, 'nick', 'nick@126.com'),
    (4, 'angel','angel@163.com'),
    (7, 'brank','ba198@126.com');

 

但是对于更新记录,由于update语法不支持一次更新多条记录,只能一条一条执行:

UPDATE t_member SET name='nick', email='nick@126.com' WHERE id=1;
UPDATE t_member SET name='angel', email='angel@163.com' WHERE id=4;
UPDATE t_member SET name='brank', email='ba198@126.com' WHERE id=7;

这里问题就出现了,倘若这个update list非常大时(譬如说5000条),这个执行率可想而知。

这就要介绍一下在MySql中INSERT语法具有一个条件DUPLICATE KEY UPDATE,这个语法和适合用在需要判断记录是否存在,不存在则插入存在则更新的记录。

具体的语法可以参见:http://dev.mysql.com/doc/refman/5.0/en/insert.html

基于上面这种情况,针对更新记录,仍然使用insert语句,不过限制主键重复时,更新字段。如下:

INSERT INTO t_member (id, name, email) VALUES
    (1, 'nick', 'nick@126.com'),
    (4, 'angel','angel@163.com'),
    (7, 'brank','ba198@126.com')
ON DUPLICATE KEY UPDATE name=VALUES(name), email=VALUES(email);

注意:ON DUPLICATE KEY UPDATE只是MySQL的特有语法,并不是SQL标准语法!

原文地址:http://www.crackedzone.com/mysql-muti-sql-not-sugguest-update.html

SVN分支与合并透析

1.创建分支的意义

创 建分支的意义,比如我们在一个基础平台上进行开发,每个技术小组负责一个子项目,而基础平台也是有可能会继续更改的,这个时候,如果不创建分支,子项目之 间会相互影响,影响最大的就是后期的测试和版本发布,子项目A已经结束,但测试却受到正在进行的子项目B的影响,测试通不过,就别说版本发布了。所以,我 们需要从目前的项目(主干trunk)中创建分支(branch),隔离子项目间的相互影响。

2.svn创建分支原理

在 svn中,创建分支,实际上就是一个版本拷贝(对应copy to...注意:绝不是简单在客户端上copy一个目录,而是svn仓库中copy,文件版本号会增加。),两边做任何修改发生的版本变化,是一套机制。 举例:目前主干版本是100,分支版本是101,主干中增加一个文件,版本为102,分支中再增加一个文件,版本就为103了。两边的版本号是一套,不会 重复。

3.svn创建分支的方法

TortoiseSVN:右键点击工程目录->TortoiseSVN->Branch/tag..菜单,From WC at Url自动为工程svn url,比如https://localhost:8443/svn/fbysss/prj1/trunk,to Url填写https://localhost:8443/svn/fbysss/prj1/branches/branch1。点OK按钮,分支就创建好了。

Subclipse:Team->Branch/tag..,跟上面类似.

SVN命令模式:svn copy trunk_path  branch_path  -m '描述'

举例:svn copy https://localhost:8443/svn/fbysss/prj1/trunk 

https://localhost:8443/svn/fbysss/prj1/branches/branch1 -m "第一个分支"

注意一点:trunk和branch不能互为子目录,否则就乱套了。

4.分支合并

1)从分支合并到主干

分支开发结束之后,往往需要合并回主干去测试、发布,但分支和主干可能有很多冲突的地方,在合并时经常需要手工解决。

被操作对象:主干

From主干的打出分支时的版本

To:分支的Head版本(最新版本)

 

怎么理解这个From和To呢?似乎跟我们的想当然不太一样:因为我们理解,把分支合并到主干,肯定是From分支,To主干。怎么搞反了呢?

实际上,Svn认为,我们要合并的,是从主干的某个版本开始,到分支的某个版本结束。两边的版本号实际上是一套系统,不会有重复。我们从TortoiseSVN Help中也能找到证据:

If you are using this method to merge a feature branch back to trunk, you need to ........

In the From: field enter the full folder URL of the trunk. This may sound wrong, but remember that the trunk is the start point to which you want to add the branch changes. You may also click ... to browse the repository. 

In the To: field enter the full folder URL of the feature branch.

 

2)从主干合并到分支

试想这样的情况:一个项目里面,要独立出来一个子项目,需要单独发布版本,用到了基础框架代码,而基础框架在主干中不断修改完善,这就需要从主干合并到分支。

被操作对象:分支

From:分支的第一个版本(最旧版本)

To:主干的Head版本(最新版本)

相当于从分支的第一个版本开始一直到主干最后一个版本结束合并之后,替换分支。

3)从分支合并到分支

有 这样的需求:一个项目中有很多分支,这些分支需要分期上线,有多个工作并行,但每一期之间不能相互影响,这就可以打出几个tag(也是分支),从主干 copy而来。其他主干根据排期分别合并到这些tag中来。比如有prjTag1和prjTag2,model1、model2需要合并到prjTag1 中,model3、model4需要合并到prjTag2中。拿prjTag1举例:

在prjTag1的work copy中,merge

 

From主干的打出分支时的版本

To:分支的Head版本(最新版本)

注意:From不是本Tag的某个版本,而是之前主干打出分支时的版本,最终Merge到prjTag1的work copy,而prjTag1是找不到当初打分支时的版本的。

原文地址:http://blog.csdn.net/fbysss/article/details/5437157