因为工作用到了事务，对事务搜索了一些牛人的帖子，整理一部分如下:
首先，mysql是否支持事务由存储引擎决定的，InnoDB存储引擎支持事务及行级锁。使用事务之前要首先确认存储引擎的类型，MyISAM不支持事务，用于只读程序提高性能。
事务具有ACID：原子性、一致性、隔离性和持久性四种特性。事务支持四种不同的隔离级别，所谓隔离级别决定了一个session中的事务可能对另一个session的影响，并发session对数据库的操作，一个session中所见数据的一致性。四种不同的隔离级别：
1）READ UNCOMMITED：最低级别的隔离，允许一个事务读取还没commit的数据，可以提高性能，但是会出现脏读：
如一个事务会读进另一个事务还没提交的数据，那就会看到一些被另一个事务回滚掉的事务；
2）READ COMMITED：只能允许事务读取已经commit的数据，不会出现脏读，但是数据可以再事务提交之前被更改，会出现两次读取不一致的情况，即读取不可复现：
一个事务读进一条记录，另一个事务更改了这条记录并提交完毕，这时另一个事务在去读取这表记录时，已经被更改了。
3）REPEATABLE READ： 事务开始后，锁定数据避免其他用户更新数据，保证了重复读取时数据的一致性，但是其他用户可以将新的幻想行插入到数据集中，且幻想行可以在该事务的后续读取中独到，也就是导致了幻影读的问题：
一个事务用Where子句来检索一个表的数据，另一个事务插入一条新的记录，并且符合Where条件，这样，第一个事务用同一个where条件来检索数据后，就会多出一条记录。
4）SERIALIZABLE：在数据集上放置一个范围锁，以防止其他用户在事务完成之前更新或插入记录，使事务串行执行，是四个隔离级别中限制最大的隔离级别，有可能会导致死锁或超时。并发度最低，慎用
| 隔离级别 | 脏读（Dirty Read） | 不可重复读（NonRepeatable Read） | 幻读（Phantom Read） |
|---|---|---|---|
| 读未提交（Read uncommitted） | 可能 | 可能 | 可能 |
| 读已提交（Read committed） | 不可能 | 可能 | 可能 |
| 可重复读（Repeatable read） | 不可能 | 不可能 | 可能 |
| 可串行化（Serializable ） | 不可能 | 不可能 | 不可能 |
根据不同需求选择不同的隔离级别。
autocommit:
mysql默认的autocommit=1，通过select @@autocommit 查看。
当autocommit=1时，默认每一条sql语句都是一个事务，执行完之后自动commit。除非遇到显示的start transaction
当autocommit=0时，sql语句执行完不会提交，直到遇到显示的commit或rollback语句。
通过set autocommit=0/1来该表autocommit。数据库初始化时默认为1，通过修改init配置文件该表autocommit。
在一个事务里面，直到事务被commit和rollback，中间的sql不会被自动commit，如果设置autocommit=0则不用显示start transaction，直接commit就可以。但是这会导致你每次的sql select等操作都需要commit。
事务嵌套：
看了很多帖子，说话不一，大部分认为mysql是不支持事务嵌套的。如下观点是统一的：
在遇到start transaction时，会隐式执行commit，提交上一个事务做出的更改，然后开始新的事务。所以，规避事务嵌套是王道，我就踩到这个坑里了。
参考：
http://hideto.iteye.com/blog/195275
http://www.cnblogs.com/wzcheng/archive/2006/10/18/532243.html 对事务四种不同的隔离级别进行了详细解释
http://www.cnblogs.com/alang85/archive/2011/11/17/2253072.html
欢迎批评指正~感谢