更新丢失（Lost Update）：当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存在，就会发生丢失更新问题-最后的更新覆盖了由其他事务所做的更新。（可以用类似乐观锁的方案解决）
脏读（Dirty Reads）：一个事务正在对一条记录做修改，在这个事务完成并提交前，这条记录的数据就处于不一致的状态；这时，另一个事务也来读取同一条记录，如果不加控制，第二个事务读取了这些“脏”数据，并据此做进一步的处理，就会产生未提交的数据依赖关系。这种现象被形象的叫做“脏读”。
一句话：事务A读取到了事务B已经修改但尚未提交的数据，还在这个数据基础上做了操作。此时，如果B事务回滚，A读取的数据无效，不符合一致性的要求。
不可重复读（Non-Repeatable Reads）：一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，却发现其读出的数据已经发生了改变、或某些记录已经被删除了！这种现象就叫做“不可重复读”。
一句话：事务A读取到了事务B已经提交的修改数据，不符合隔离性。
幻读（Phantom Reads）：一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据，这种现象就称为“幻读”。
一句话：事务A读取到了事务B已经提交的新增数据，不符合隔离性。
事务的隔离级别
“脏读”、“不可重复读”、“幻读”，其实都是数据库读一致性问题，必须由数据库提供一定的事务隔离机制来解决。
数据库的事务隔离级别越严格，并发副作用越小，但付出的性能代价也就越大，因为事务隔离实质上就是使事务在一定程度上“串行化”进行，这显然与“并发”是矛盾的。
查看当前数据的事务隔离级别：show variables like 'tx_isolation'
设置事务隔离级别：set tx_isolation='REPEATABLE-READ'
MySQL默认的隔离级别是可重复读。
2）行锁案例分析
用下面的表演示，需要开启事务，session_1更新某一行，session_2同时更新某一行将被阻塞，但是更新其他行正常
3）隔离级别案例分析
CREATE TABLE `account` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键id',
`name` varchar(255) DEFAULT NULL COMMENT '名称',
`balance` int(11) DEFAULT NULL COMMENT '金额',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8
insert into `account` (`id`, `name`, `balance`) values('1','lilei','450');
insert into `account` (`id`, `name`, `balance`) values('2','hanmei','16000');
insert into `account` (`id`, `name`, `balance`) values('3','lucy','2400');
① 读未提交：
a. 打开一个客户端A，并设置当前事务隔离级别为read uncommitted（读未提交），set tx_isolation='read-uncommitted'，查询account表的初始值：
b. 在客户端A的事务提交之前，打开另一个客户端B，并设置当前事务隔离级别为read uncommitted，更新account表：
c. 这时，虽然客户端B的事务还没提交，但是客户端A就可以查询到B已经更新的数据：
d. 一旦客户端B的事务因为某种原因回滚，所有的操作都将会被撤销，那客户端A查询到的数据其实就是脏数据：
