1、什么是事务：数据库中的事务是指逻辑上的一组操作，这组操作要么都执行成功，要么都不执行成功。
2、事务的管理：默认情况下Mysql会自动管理事务，一条SQL语句独占一个事务。
也可以使用start transaction、rollback和commit人为方式管理。
在start
transaction之后的多条语句就是一个事务，事务commit之前可以rollback。
3、在JDBC中管理事务：
connection.setAutoCommit(false);
connection.rollback();
connection.commit();
多语句时可以创建回滚点：
SavePoint sp =
connection.setSavePoint();
connection.rollback(sp);
4、事务的四大特性：
(1)原子性：是指事务是一个不可分割的整体，事务中的操作要么全部发生，要么一个都不发生。
(2)一致性：事务处理前后数据的完整性必须保持一致。
完整性是指一个数据在某个时间点完全满足数据库中约束的要求。
(3)隔离性：是指多个用户访问同一个数据库时，一个用户的事务处理不能被其他用户的事务干扰，多个并发事务之间的数据要相互隔离。
(4)持久性：是指一个事务一旦被提交，它对数据库中的数据改变是永久的。
5、一些概念：
(1)脏读：一个事务读到另一个事务未提交的数据
(2)不可重复读：在一个事务中多次读取某一数据同的结果（一个事务读到另一个事务已经提交的数据）
(3)虚读幻读：是指一个事务内读到其他事务插入的数据，导致前后读取不一致（一个事务读到另一个事务已经提交的数据）
6、隔离级别：
查看当前隔离级别：select @@tx_isolation
设置隔离级别：set [session/global] transaction
isolation level read
uncommitted
session:只针对当前会话有效，默认为session
global:修改数据库默认隔离级别
Mysql默认隔离级别：repeatable
read
(1)read uncommitted -- 数据库会出现脏读、不可重复读、虚读幻读问题
(2)read committed --
数据库防止出现脏读，不防止不可重复读和虚读幻读问题
(3)repeatable read --
数据库防止脏读、不可重复读问题，但不能防止虚读幻读问题
(4)serializable --
数据库运行在单线程模式，所有的问题都会防止
7、锁
(1)排他锁：排他锁和任何锁都不能共存，在任何隔离级别下进行修改都会加排他锁
(2)共享锁：共享锁只能和共享锁共存，在非serializable级别下查询不加任何锁，在serializable级别下查询加共享锁。
8、线程安全问题
多个用户同时对同一数据进行并发修改操作时，就会导致线程安全问题的发生，使用锁机制保证同一时间只有一个线程能访问数据，这样虽然解决了线程安全问题，但由于同一时间只能有一个线程访问该数据，使得数据库的效率非常低。为了找到合适的解决方案，得先对事务的处理有个更深的认识。
(1)如果多个线程同时对同一数据做修改，一定会有线程安全问题，必须解决。
任何隔离级别下做修改操作，都会加排他锁，保证同一时间只能有一个线程访问数据。
(2)如果多个线程同时对同一数据做查询操作，不会产生线程安全问题，无需处理。
(3)如果多个线程都未运行在serializable级别，则查询都不加锁，不会排斥。
(4)如果多个线程都运行在serializable级别，则都加共享锁，不会排斥。
(5)如果多个线程中有serializable，也有其他，则serializable加共享锁，其他不加，不会排斥。
(6)如果一个线程修改数据，其他线程查询时，可能出现脏读、不可重复读、虚读幻读。但不是任何时候都会出现问题，只在某些应用场景才可能造成问题。
(7)在serializable隔离级别下查询加共享锁，共他客户端无论是什么隔离级别只要做修改操作，就加排他锁，只能等待，从而解决虚读幻读问题。
9、更新丢失问题
两个查询对同一个查询结果做修改，后修改会忽略先修改的结果，从而造成先修改的结果丢失。
解决方案一：将数据库隔离级别设置为serializable可避免更新结果丢失，但这样使得数据库效率低下，所以不会这么做。
解决方案二：锁机制
(1)乐观锁：假定每次都不会造成更新丢失，在数据库中增加一版本字段，每次更新都基于上一版本进行。
(2)悲观锁：假定每次都会造成更新丢失，在查询时手动加排他锁（select
... for update）。
如果查询多，修改少应使用乐观锁，减少锁表操作；
如果修改多，查询少应使用悲观锁，减少修改失败。
10、演示不同隔离级别下的并发问题：
假定有如下表，模拟银行转账的操作。
CREATE
TABLE `card` (
`id` int(11) NOT NULL auto_increment,
`name`
varchar(20) default NULL,
`money` double default NULL,
PRIMARY KEY
(`id`)
);
INSERT INTO `card` VALUES(NULL,‘john‘,1000);
INSERT INTO `card` VALUES(NULL,‘mary‘,1000);
set transaction
isolation level 设置事务隔离级别
select @@tx_isolation 查询当前事务隔离级别
(1)当把事务的隔离级别设置为read uncommitted时，会引发脏读、不可重复读和虚读
A窗口
set transaction isolation level read uncommitted;
start
transaction;
select * from card;
-----发现a帐户是1000元，转到b窗口
B窗口
start transaction;
update card set money=money+100 where
name=‘aaa‘;
-----不要提交，转到a窗口查询
select * from card
-----发现a多了100元，这时候a读到了b未提交的数据（脏读）
(2)当把事务的隔离级别设置为read committed时，会引发不可重复读和虚读，但避免了脏读
A窗口
set transaction isolation level read committed;
start
transaction;
select * from
card;
-----发现a帐户是1000元，转到b窗口
B窗口
start transaction;
update card
set money=money+100 where name=‘aaa‘;
commit;
-----转到a窗口
select * from
card;
-----发现a帐户多了100,这时候，a读到了别的事务提交的数据，两次读取a帐户读到的是不同的结果（不可重复读）
(3)当把事务的隔离级别设置为repeatable read(mysql默认级别)时，会引发虚读，但避免了脏读、不可重复读
A窗口
set transaction isolation level repeatable read;
start
transaction;
select * from card;
----发现表有4个记录，转到b窗口
B窗口
start transaction;
insert into card(name,money)
values(‘ggg‘,1000);
commit;
-----转到 a窗口
select * from card;
----可能发现表有5条记如，这时候发生了a读取到另外一个事务插入的数据（虚读）
(4)当把事务的隔离级别设置为Serializable时，会避免所有问题
A窗口
set transaction isolation
level Serializable;
start transaction;
select * from
card;
-----转到b窗口
B窗口
start transaction;
insert into card(name,money)
values(‘ggg‘,1000);
-----发现不能插入，只能等待a结束事务才能插入