是指作为单个逻辑工作单元执行的一系列操作,要么完全地执行,要么完全地不执行
例如:A给B转帐,这里存在两个操作,一个是A账户扣款1000元,两一个操作是B账户增加1000元,两者就构成了转账这个事务。 两个操作都成功,A账户扣款1000元,B账户增加1000元,事务成功两个操作都失败,A账户和B账户金额都没变,事务失败
事务的操作:先定义开始一个事务,然后对数据作修改操作,这时如果提交(COMMIT),这些修改就永久地保存下来,如果回退(ROLLBACK),数据库管理系统将放弃您所作的所有修改而回到开始事务时的状态。
在 MySQL 命令行的默认设置下,事务都是自动提交的,即执行 SQL 语句后就会马上执行 COMMIT 操作。因此要显式地开启一个事务务须使用命令 BEGIN 或 START TRANSACTION,或者执行命令 SET AUTOCOMMIT=0,用来禁止使用当前会话的自动提交。
脏读: A事务读到B事务还未提交数据。如果恰巧B事务回滚,那么A事务读到的数据时不被承认的。
不可重复读: A事务读到了B事务已提交的更改数据 ,造成了前后查询结果不一致。
幻读: A事务读到了B事务提交的新增数据,造成前后查询结果不一致
允许你读取还未提交的改变了的数据。可能导致脏、幻、不可重复读(相当于没有做任何事务隔离)
允许在并发事务已经提交后读取。可防止脏读,但幻读和 不可重复读仍可发生(ORACLE默认级别)
对相同字段的多次读取是一致的,重复读,就是在开始读取数据(事务开启)时,不再允许修改操作。可防止脏、不可重复读,但幻读仍可能发生。(MYSQL默认级别)
是最高的事务隔离级别,在该级别下,事务串行化顺序执行,可以避免脏读、不可重复读与幻读。但是这种事务隔离级别效率低下,比较耗数据库性能,一般不使用(ORACLE支持)
数据库的隔离级别除了SERIALIZABLE,都不能处理第一类丢失更新和第二类丢失更新;所以,数据库提供了锁机制来防止第一类丢失更新和第二类丢失更新。
从数据库系统角度分为三种:排他锁、共享锁、更新锁。 从程序员角度分为两种:一种是悲观锁,一种乐观锁。 从锁的粒度分:表锁、行锁。
悲观地认为每次自己去拿数据的时候别人会修改数据,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会阻塞直到它拿到锁。传统的关系数据库里用到了很多这种锁机制,比如行锁、表锁、读锁、写锁等,都是在操作之前先上锁。
1、共享锁(Share locks简记为S锁) 又叫读锁,其他事务可以读A但在事务T在释放A上的共享锁前不能对A做任何修改。
select ... lock in share mode(加共享锁)2、排他锁(Exclusive Lock简记为X锁) 又叫写锁,其他事务在T事务释放数据A上的锁之前都不能再读取和修改A。
select ...for update(加排他锁)3、更新锁(简记为U锁) 在修改操作的初始化阶段用来锁定可能要被修改的资源,这样可以避免使用共享锁造成的死锁现象。
因为当使用共享锁时,修改数据的操作分为两步: 首先获得一个共享锁,读取数据,然后将共享锁升级为排他锁,再执行修改操作。这样如果有两个或多个事务同时对一个事务申请了共享锁,在修改数据时,这些事务都要将共享锁升级为排他锁。这时,这些事务都不会释放共享锁,而是一直等待对方释放,这样就造成了死锁。 如果一个数据在修改前直接申请更新锁,在数据修改时再升级为排他锁,就可以避免死锁。
mysql InnoDB引擎默认的修改数据语句,update,delete,insert都会自动给涉及到的数据加上排他锁,select语句默认不会加任何锁类型,如果加排他锁可以使用select …for update语句,加共享锁可以使用select … lock in share mode语句。
所以加过排他锁的数据行在其他事务种是不能修改数据的,也不能通过for update和lock in share mode锁的方式查询数据,但可以直接通过select …from…查询数据,因为普通查询没有任何锁机制。
1、行锁:锁的作用范围是行级别。 2、表锁:锁的作用范围是整张表。 数据库能够确定那些行需要锁的情况下使用行锁,如果不知道会影响哪些行的时候就会使用表锁。
举个例子,一个用户表user,有主键id和用户生日birthday。 当你使用update … where id=?这样的语句时,数据库明确知道会影响哪一行,它就会使用行锁; 当你使用update … where birthday=?这样的的语句时,因为事先不知道会影响哪些行就可能会使用表锁。
乐观地认为每次去拿数据的时候别人不会修改数据,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,需要用户自己去实现。 既然都有数据库提供的悲观锁可以方便使用为什么要使用乐观锁呢?
对于读操作远多于写操作的时候,大多数都是读取,这时候一个更新操作加锁会阻塞所有读取,降低了吞吐量。最后还要释放锁,锁是需要一些开销的,我们只要想办法解决极少量的更新操作的同步问题。换句话说,如果是读写比例差距不是非常大或者你的系统没有响应不及时,吞吐量瓶颈问题,那就不要去使用乐观锁,它增加了复杂度,也带来了额外的风险
悲观锁一般就是我们通常说的数据库锁机制,乐观锁一般是指用户自己实现的一种锁机制
1、 版本号(version)
1. 给表添加一个额外的数字类型字段version 2. 在insert一个对象的时候初始化version值为0 3. 在select的时候,查询出对象的版本号 4. 在update的时候 1. 更新版本号,version = version+1 2. 在update的where条件中带上当前更新对象的版本号 where .. and version = ? 3. 如果update返回影响条数>0,说明更新成功 4. 如果update返回影响条数=0,说明更新的对象已经被其他事务更新或者删除,抛出异常,回滚当前事务2、时间戳(timestamp) 和版本号基本一样,只是通过时间戳来判断而已,注意时间戳要使用数据库服务器的时间戳不能是业务系统的时间。 3、CAS算法 即compare and swap(比较与交换),是一种有名的无锁算法。无锁编程,即不使用锁的情况下实现多线程之间的变量同步,也就是在没有线程被阻塞的情况下实现变量的同步,所以也叫非阻塞同步(Non-blocking Synchronization)。CAS算法涉及到三个操作数
* 需要读写的内存值 V * 进行比较的值 A * 拟写入的新值 B当且仅当 V 的值等于 A时,CAS通过原子方式用新值B来更新V的值,否则不会执行任何操作(比较和替换是一个原子操作)。一般情况下是一个自旋操作,即不断的重试。
MySQL中的数据用各种不同的技术存储在文件(或者内存)中。这些技术中的每一种技术都使用不同的存储机制、索引技巧、锁定水平并且最终提供广泛的不同的功能和能力。
通过选择不同的技术,你能够获得额外的速度或者功能,从而改善你的应用的整体功能。
1、MyISAM是非事务安全的,而InnoDB是事务安全的 2、MyISAM锁的粒度是表级的,而InnoDB支持行级锁 3、MyISAM支持全文类型索引,而InnoDB不支持全文索引 4、MyISAM相对简单,效率上要优于InnoDB,小型应用可以考虑使用MyISAM 5、MyISAM表保存成文件形式,跨平台使用更加方便