事务：一组原子性的SQL查询。如果数据库能够成功的对数据库应用该组查询的全部语句，那么就执行改组查询；否则所有的语句都不会执行。
ACID：原子性(atomocity)，一致性(consistency)，隔离性(isolation)，持久性(durability)。
原子性：一个事务必须被视为不可分割的最小执行单元。整个事物的操作要么全部提交成功，要么全部失败回滚，不可能存在只执行了一部分的操作。
一致性：数据库总是从一个一致性的状态转移到另一个一致性的状态。即使中间出现问题，因为事务没有提交，事务造成的修改也不会保存到数据库中。
隔离性：一个事务所做的修改在最终提交以前，对其他事务是不可见的。例如从一个账户向另一个账户转账，从其他事务角度来看是一瞬间的操作，不会出现短暂的金额总数不匹配的问题。
持久性：一旦事务提交，其所做的修改就会被永久的保存在数据库中。
四种隔离级别：
READ UNCOMMITTED：未提交读
事务中的修改，即使未被提交，对其他事务也是可见的。
脏读：事务可以读取未提交的数据。
READ COMMITTED： 提交读
大部分数据库系统的默认隔离级别（MySQL不是），一个事务开始时，只能“看见”已经提交的事务所作的修改。也可叫做不可重复读（nonrepeatable read） ，因为执行同样的查询，两次得到的数据可能不同。
REPEATABLE READ：可重复读
MySQL默认隔离级别。解决了脏读的问题，同时保证了在同一事务中多次读取同样的记录结果相同。然而可能会导致幻读（Phantom Read），某一个事务在读取某一个范围的记录时，另一个事务又在该范围内插入新的记录，当之前的事务再次读取该范围的记录时，就会产生幻行。
SERIALIZABLE： 可串行化
最高的隔离级别。强制事务串行执行，避免了幻读情况的发生。相当于在每一行数据上都加锁，会导致大量的超时和锁争用的问题，现实开发中很少使用该隔离级别。
死锁：两个或多个事务在同一资源上相互争夺对方占用，并请求锁定对方的资源，从而导致恶性循环的现象。
举例：
事务1:
start transaction;
update StockPrice set ... where id = 3;
update StockPrice set ... where id = 4;
commit;
事务2:
start transaction;
update StockPrice set ... where id = 4;
update StockPrice set ... where id = 3;
commit;
解决死锁：死锁检测，死锁超时机制。
MySQL的事务： InnoDB; NDB Cluster
第三方存储引擎：XtraDB, PBXT
自动提交(AUTOCOMMIT)：如果不是显式的开始一个事务，则每个查询都被当作一个事务执行提交操作
MVCC（多版本并发控制）：MySQL, Oracle, PostgreSQL
是行级锁的一个变种，但它在很多情况下避免了加锁操作，因为开销更低。
InnoDB：通过每行记录后面保存的两个隐藏的列来实现，分别是行的创建时间和行的过期时间（删除时间）。存储的不是实际的时间值而是系统版本号。
每开始一个新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询到的每行记录的版本号进行比较。
SELECT:
InnoDB会根据以下两个条件检查每行记录：
a. InnoDB只查找版本号早于当前事务版本的数据行，这样可以确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改的
b. 行的删除版本要么未定义，要么大于当前事务的版本号。则可以确保事务读取到的行，在事务开始之前未被删除。
Insert：
InnoDB为新插入的每一行保存当前的系统版本号作为行版本号
DELETE:
InnoDB为删除的每一行保存当前的系统版本号作为行删除标识
UPDATE:
InnoDB为插入一行新纪录，保存当前的系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为行删除标识
MyISAM存储引擎：全文索引，亚索，空间函数，但不支持事务和行级锁，不支持崩溃后的安全恢复。
Archive引擎：只支持insert和select操作
Blackhole引擎：没有实现任何的存储机制，会丢弃所有插入的数据，不作任何保存，但服务器会记录Blackhole表的日志，可以用于复制数据到备库。
CSV引擎：将普通的CSV文件作为MySQL的表来处理，但这种表不支持索引。
选择合适的引擎：
1. 大部分情况下InnoDB都是正确的选择，“除非需要用到某些InnoDB不具备的特性，并且没有其他办法可以替代，否则都应该优先选择InnoDB”
2. 除非万不得已，否则建议不要混合使用多种存储引擎，否则可能带来一系列复杂的问题，以及一些潜在的bug和边界问题。
总结：MySQL拥有分层的架构。上层是服务器层的服务和查询执行引擎，下层则是存储引擎。
