http://blog.chinaunix.net/uid-22606185-id-3252443.html
一、 什么是事务
事务就是一段sql 语句的批处理，但是这个批处理是一个atom（原子） ，不可分割，要么都执行，要么回滚（rollback）都不执行。
二、为什么出现这种技术
为什么要使用事务这个技术呢？ 现在的很多软件都是多用户，多程序，多线程的，对同一个表可能同时有很多人在用，为保持数据的一致性，所以提出了事务的概念。这样很抽象，举个例子：
A 给B 要划钱，A 的账户-1000元， B 的账户就要+1000元，这两个update 语句必须作为一个整体来执行，不然A 扣钱了，B 没有加钱这种情况很难处理（找出原因）。
三、如何在MYSQL 中使用事务
1、谁可以使用
只有InnoDB /BDB 的之类的transaction_safe table 才能支持。
默认的engine MyISAM 是不支持事务的，show engine 可以看到支持的和默认的engine。可以在[mysqld] 加入： default_storage_engine=InnoDB; InnoDB 就是建立表的默认引擎。
建立InnoDB 表：Create table .... type=InnoDB； Alter table table_name type=InnoDB;（如何查看已有表的类型： show create table table_name)
这样我们就可以在InnoDB 表上进行事务操作了！
2、如何使用
启动事务的方法：
认为分为两种：
1、begin ，rollback,commit .当然有的人用begin /begin work .推荐用START TRANSACTION 是SQL-99标准启动一个事务。
start transaction；
update from account set money=money-100 where name='a';
update from account set money=money+100 where name='b';
commit；
解释： 这样start transaction 手动开启事务，commit 手动关闭事务。
2、默认的时候autocommit=1 自动提交是开启的，所以你可以理解为每条语句一输入到mysql就commit 了。当你 set autocommit=0 时候，你可以这样：
update from account set money=money-100 where name='a';
update from account set money=money+100 where name='b';
commit；
// 默认都不提交，只有手动键入commit 时候才上述都提交。
综述：一般使用１ 方法。
1.脏读：如果有A向B 做了这个操作：update account set money=money+100 where name='B'；在没有commit 之前B 查询：select money from account where name='B'；找到了没有提交的money ，之后A在此时有rollback ，B 再查询，100 不见了。为了避免提高级别：read committed 。就是只能读取提交后的东东。
2.不可重复读：1中说明的就是我们不能读取一个事务的中间状态。 而重复读是指我们每次读取到的结果都要一致。 这个也是mysql 默认的级别。
mysql> select @@tx_isolation ;
+-----------------+
| @@tx_isolation |
+-----------------+
| REPEATABLE-READ |
+-----------------+
3.幻读：在一个事务内读取到了别的事务插入的数据，导致前后读取不一致。和不可重复读的区别是：不可重复读是读取到了别人对表中的某一条记录进行了修改，导致前后读取的数据不一致。 幻读是前后读取到表中的记录总数不一样，读取到了其它事务插入的数据。比如现在有 A 和 B 两个应用程序，他们并发访问了数据库中的某一张表，假设表中有 3 条记录，B 执行查询操作， 第一次查询表得到了 3 条记录。此时 A 对表进行了修改，增加了一条记录，当 B 再次查询表的时候，发现多了一条数据。这种情况就造成了 B 的幻读。但是幻读是不一定每次都发生的，这种情况是不确定的。为了避免幻读，我们可以将事物隔离级别设置为 serializable 如果设置成了这种级别，那么数据库就变成了单线程访问的数据库，导致性能降低很多。
summary：
（1）Serializable：可避免脏读、不可重复读、幻读情况的发生。
（2）Repeatable read：可避免脏读、不可重复读情况的发生。（可重复读，是 mysql 默认的事务隔离级别）
（3）Read committed：可避免脏读情况发生。（读取已提交的数据）
（4）Read uncommitted：最低级别，以上情况均无法保证。（读取到了未提交的数据）
当我们将数据库的隔离级别设置为：Serializable 的时候，虽然可以避免所有并发访问的问题，但是 Serializable 采用的是单线程来解决并发访问的问题，也就是说在某一段时间内，只能有一个用户对数据库进行操作，导致其它用户阻塞。导致数据库的访问性能很差。
1.读未提交（Read Uncommitted）：这种隔离级别可以让当前事务读取到其它事务还没有提交的数据。这种读取应该是在回滚段中完成的。通过上面的分析，这种隔离级别是最低的，会导致引发脏读，不可重复读，和幻读。
2.读已提交（Read Committed）：这种隔离级别可以让当前事务读取到其它事务已经提交的数据。通过上面的分析，这种隔离级别会导致引发不可重复读，和幻读。
3.可重复读取（Repeatable Read）：这种隔离级别可以保证在一个事务中多次读取特定记录的时候都是一样的。通过上面的分析，这种隔离级别会导致引发幻读。
4.串行（Serializable）：这种隔离级别将事务放在一个队列中，每个事务开始之后，别的事务被挂起。同一个时间点只能有一个事务能操作数据库对象。这种隔离级别对于数据的完整性是最高的，但是同时大大降低了系统的可并发性。
五、非InnoDB怎么办？
妈的，肯定有人会说那我mysql 的默认MyISAM 怎么办？ 没有事务这样的事情怎么处理呢？ 这个要用到另外一种技术叫做LOCK ! 实际上实现上边那4 个安全级别的所用的技术就是LOCK ！
我怎么在处理锁的问题上，经常听到：共享锁、排它锁、悲观锁、乐观锁、行级锁、表级锁。
共享锁： 就是在读取数据的时候，给数据添加一个共享锁。共享和共享直接是不冲突的，但是和排他锁是冲突的。
排他锁： 更新数据的时候，安装排他锁，禁止其他一切行为。
场景：老公去在 ATM 上取钱，老婆在柜台存钱，假设这个账户中有 1000 元。老公首先执行查询操作，查询到账户余额为 1000 此时程序将 1000 拿到内存中，老公取了 200 元，程序就执行了更新操作将账户余额改为 800，但是当老公的程序没有 commit 的时候，老婆查询账户，此时账户余额还是 1000 元，老婆存入 200 元，程序执行了更新操作将账户余额改为 1200，然后老公将更新语句提交，接着老婆也将更新语句提交。最后导致的结果就是该账户的余额为 1200，这就是更新丢失的问题。引发更新丢失的根源就是查询上，因为双方都是根据从数据库查询到的数据再对数据库中的数据进行更新的。解决更新丢失有三个方案：(1) 将事务隔离级别设置为最高，采用死锁策略。(2) 采用悲观锁，悲观锁不是数据库中真正的锁，是人们看待事务的态度。(3) 采用乐观锁，乐观锁也不是数据库中真正的锁。
如果我们采用的是第一个方案时，老公进行查询操作，数据库为表增加了共享锁，老婆进行查询操作时数据库也增加了一个共享锁。但是当老公进行更新数据库操作时，由于老婆拿着共享锁，导致老公不能增加排它锁，老婆进行更新操作时，因为老公拿着共享锁，导致老婆也拿不到排它锁，这就发生了死锁现象，你等我，我等你。在 mysql 中，处理死锁的方案是释放掉一方的锁。这样就保证了一方更新成功，但是这种性能极低，因为数据库频繁在解决死锁问题。
悲观锁（更新多，查询少时用）
顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁
如果我们采用的是第二个方案时，即采用悲观锁。就是我们在操作数据库时采用悲观的态度，认为别人会在此时并发访问数据库。我们在查询语句中 select * from account where name='aaa' for update; 等于加了排它锁。当老公查询余额的时候，select money from account where name='aaa' for update; 增加了排它锁，老婆查询账户余额的时候， select money from account where name='aaa' for update；也要求对数据库加排它锁，因为老公已经拿到了排它锁，导致老婆不能加锁，所以老婆只有等待老公执行完毕，释放掉锁以后才能继续操作。
乐观锁（更新少，查询多时用）
顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁
如果我们采用的是第三个方案时，即采用乐观锁，就是我们在操作数据库的时候会认为没有其它用户并发访问，但是乐观锁也不是完全乐观的，乐观锁是采用版本号的方式进行控制的。在数据库表中有一列版本号。从数据库中查询的时候，将版本号也查询过来，在进行更新操作的时候，将版本号加1，查询条件的版本号还是查询过来的版本号。比如，老公执行查询操作的时候，select money,version from account where name='aaa'; 假设此时查询到的版本号为 0，老公在进行更新操作的时候 update account set money=money+100,version=version+1 where name='aaa' and version=0; 未提交时老婆来查询，查询到的版本号依然是 0，老婆也执行更新操作 update account set money=money+100,version=version+1 where name='aaa' and version=0; 现在老公提交了事务，老婆再提交事务的时候发现版本号为 0 的记录没有了，所以就避免了数据丢失的问题。不过这种情况也导致了多个用户更新操作时，只有一个用户的更新被执行。
Mysql事务以及加锁机制
事务的特征ACID，即原子性、一致性、隔离性、持久性。
原子性保证一个事务为一个最小的单元，内部不可分割；
一致性保证事务中的每个操作线程不可单独提交，成功则一起提交，不成功则事务回滚；
隔离性保证不同事务间看到的数据视图相互独立，相互隔离（隔离级别可设置）；
持久性保证事务提交后数据会持久的保存下来；
mysql分页查询策略
对于有大数据量的mysql表来说，使用LIMIT分页存在很严重的性能问题。
查询从第1000000之后的30条记录：
SQL代码1：平均用时6.6秒 SELECT * FROM `cdb_posts` ORDER BY pid LIMIT 1000000 , 30
SQL代码2：平均用时0.6秒 SELECT * FROM `cdb_posts` WHERE pid >= (SELECT pid FROM `cdb_posts` ORDER BY pid LIMIT 1000000 , 1) LIMIT 30
因为要取出所有字段内容，第一种需要跨越大量数据块并取出，而第二种基本通过直接根据索引字段定位后，才取出相应内容，效率自然大大提升。
可以看出，越往后分页，LIMIT语句的偏移量就会越大，两者速度差距也会越明显。
实际应用中，可以利用类似策略模式的方式去处理分页，比如判断如果是一百页以内，就使用最基本的分页方式，大于一百页，则使用子查询的分页方式。