什么是事务
数据库的事务（Transaction）是一种机制、一个操作序列，包含了一组数据库操作命令。事务把所有的命令作为一个整体一起向系统
提交或撤销操作请求，即这一组数据库命令要么都执行，要么都不执行，因此事务是一个不可分割的工作逻辑单元。
在数据库系统上执行并发操作时，事务是作为最小的控制单元来使用的，特别适用于多用户同时操作的数据库系统。例如，航空公司的订票系统、银行、保险公司以及证券交易系统等。
事务的特性（ACID）
① 原子性：事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用；
例如转账的这两个关键操作（将张三的余额减少200元，将李四的余额增加200元）。要么全部完成，要么全部失败。
② 一致性： 确保从一个正确的状态转换到另外一个正确的状态，这就是一致性。例如转账业务中，将张三的余额减少200元，中间发生断电情况，
李四的余额没有增加200元，这个就是不正确的状态，违反一致性。又比如表更新事务，一部分数据更新了，但一部分数据没有更新，这也是违反一致性的；
③ 隔离性：并发访问数据库时，一个用户的事务不被其他事务所干扰，各并发事务之间数据库是独立的；
④ 持久性：一个事务被提交之后，对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。
数据库隔离级别及原理
Read Uncommitted（读未提交）
Read Committed（读已提交）
Repeatable Read（可重复读）
Serializable（可序列化）
锁类型简述
共享锁(S锁):假设事务T1对数据A加上共享锁，那么事务T2可以读数据A，不能修改数据A。
排他锁(X锁):假设事务T1对数据A加上排他锁，那么事务T2不能读数据A，不能修改数据A。
各个隔离级别锁应用
读未提交
Read Uncommitted：最低隔离级别，什么都不要做，一个事务可以读到另一个事务未提交的结果。所有的并发事务问题都会发生。
原理：
事务对当前读取的数据不加锁；
事务对数据更新前添加 行级共享锁，直到事务结束才释放。
可能发生的情况：
事务1读取某些数据记录时，事务2也能对这些记录进行读取、更新；当事务2对这些记录进行更新时，事务1再次读取记录，能读到事务2对该记录的修改版本，即使更新尚未提交。
事务1更新某些数据记录时，事务2不能对这行记录做更新，直到事务1结束。
简单地理解就是：
允许事务同时读数据
允许一个事务读取数据同时另外一个事务修改数据
必须等更新数据的事务执行完成后，才能对执行其他的读取或者修改该数据的事务
读已提交
Read Committed：只有在事务提交后，其更新结果才会被其他事务看见。可以解决脏读问题。
原理：
事务对当前被读取的数据加 行级共享锁（当读到时才加锁），一旦读完该行，立即释放该行级共享锁；
事务在更新某数据的瞬间（就是发生更新的瞬间），必须先对其加 行级排他锁，直到事务结束才释放。
可能发生的情况：
事务1读取某行记录时，事务2也能对这行记录进行读取、更新；当事务2对该记录进行更新时，事务1再次读取该记录，读到的只能是事务2对其更新前的版本，要不就是事务2提交后的版本。
事务1更新某行记录时，事务2不能对这行记录做更新，直到事务1结束。
简单地理解就是：
允许事务同时读数据
必须一个事务读取完数据后，另外一个事务才能修改该数据
必须等更新数据的事务执行完成后，才能对执行其他的读取或者修改该数据的事务
可重复读
Repeated Read：在一个事务中，对于同一份数据的读取结果总是相同的，无论是否有其他事务对这份数据进行操作，以及这个事务是否提交。可以解决脏读、不可重复读。
原理：
事务在读取某数据的瞬间（就是开始读取的瞬间），必须先对其加 行级共享锁，直到事务结束才释放；
事务在更新某数据的瞬间（就是发生更新的瞬间），必须先对其加 行级排他锁，直到事务结束才释放。
可能发生的情况：
事务1读取某行记录时，事务2也能对这行记录进行读取、更新；当事务2对该记录进行更新时，事务1再次读取该记录，读到的仍然是第一次读取的那个版本。
事务1更新某行记录时，事务2不能对这行记录做更新，直到事务1结束。
简单地理解就是：
允许事务同时读数据
必须等读取数据的事务执行完成后，才能对执行其他的修改该数据的事务
必须等更新数据的事务执行完成后，才能对执行其他的读取或者修改该数据的事务
可序列化
Serialization：事务串行化执行，隔离级别最高，牺牲了系统的并发性。可以解决并发事务的所有问题。
事务在读取某数据的瞬间（就是开始读取的瞬间），必须先对其加 行级共享锁，直到事务结束才释放；
事务在更新某数据的瞬间（就是发生更新的瞬间），必须先对其加 行级排他锁，直到事务结束才释放。
可能发生的情况：
事务1读取某行记录时，事务2也能对这行记录进行读取、更新；当事务2对该记录进行更新时，事务1再次读取该记录，读到的仍然是第一次读取的那个版本。
事务1更新某行记录时，事务2不能对这行记录做更新，直到事务1结束。
简单地理解就是：
所有的事务必须等上一个事务执行完成后才开始执行
MySQL 存储引擎 MyISAM 与 InnoDB 两种存储引擎的区别
一、InnoDB支持事务，MyISAM不支持，这一点是非常之重要。事务是一种高级的处理方式，如在一些列增删改中只要哪个出错还可以回滚还原，而MyISAM就不可以了。
二、MyISAM适合查询以及插入为主的应用，InnoDB适合频繁修改以及涉及到安全性较高的应用
三、InnoDB支持外键，MyISAM不支持
四、MySQL 在 5.1 之前版本默认存储引擎是 MyISAM，5.1 之后版本默认存储引擎是 InnoDB
五、InnoDB不支持FULLTEXT类型的索引
六、InnoDB中不保存表的行数，如select count(*) from table时，InnoDB需要扫描一遍整个表来计算有多少行，但是MyISAM只要简
单的读出保存好的行数即可。注意的是，当count(*)语句包含where条件时MyISAM也需要扫描整个表
七、对于自增长的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中可以和其他字段一起建立联合索引
八、清空整个表时，InnoDB是一行一行的删除，效率非常慢。MyISAM则会重建表
九、InnoDB支持行锁（某些情况下还是锁整表，如 update table set a=1 where user like ‘%lee%’
通过以上九点区别，结合个人博客的特点，推荐个人博客系统使用MyISAM，因为在博客里主要操作是读取和写入，很少有链式操
作。所以选择MyISAM引擎使你博客打开页面的效率要高于InnoDB引擎的博客，当然只是个人的建议，大多数博客还是根据实际情
况下谨慎选择。
一些关于MyISAM与InnoDB选择使用：
MYISAM和INNODB是Mysql数据库提供的两种存储引擎。两者的优劣可谓是各有千秋。INNODB会支持一些关系数据库的高级功
能，如事务功能和行级锁，MYISAM不支持。MYISAM的性能更优，占用的存储空间少。所以，选择何种存储引擎，视具体应用而
定。
如果你的应用程序一定要使用事务，毫无疑问你要选择INNODB引擎。但要注意，INNODB的行级锁是有条件的。在where条件没有使用主键时，照样会锁全表。
比如DELETE FROM mytable这样的删除语句。如果你的应用程序对查询性能要求较高，就要使用MYISAM了。MYISAM索引和数据是分开的，而且其索引是压缩的，可以更好地利用内存。
所以它的查询性能明显优于INNODB。
压缩后的索引也能节约一些磁盘空间。MYISAM拥有全文索引的功能，这可以极大地优化LIKE查询的效率。
有人说MYISAM只能用于小型应用，其实这只是一种偏见。如果数据量比较大，这是需要通过升级架构来解决，比如分表分库，而不是单纯地依赖存储引擎。
关于Mysql数据库默认的存储引擎：
MyISAM和InnoDB是MySQL的两种存储引擎。
如果是默认安装，那就应该是InnoDB，你可以在my.ini文件中找到default-storage-engine=INNODB；当然你可以在建表时指定相应的存储引擎。
通过show create table xx 可以看见相应信息。
Mysql中InnoDB和MyISAM的比较
MyISAM：
每个MyISAM在磁盘上存储成三个文件。第一个文件的名字以表的名字开始，扩展名指出文件类型。.frm文件存储表定义。数据文件的扩展名为.MYD (MYData)。
MyISAM表格可以被压缩，而且它们支持全文搜索。不支持事务，而且也不支持外键。如果事物回滚将造成不完全回滚，不具有原子
性。在进行update时进行表锁，并发量相对较小。如果执行大量的SELECT，MyISAM是更好的选择。
MyISAM的索引和数据是分开的，并且索引是有压缩的，内存使用率就对应提高了不少。能加载更多索引，而Innodb是索引和数据是
紧密捆绑的，没有使用压缩从而会造成Innodb比MyISAM体积庞大不小
MyISAM缓存在内存的是索引，不是数据。而InnoDB缓存在内存的是数据，相对来说，服务器内存越大，InnoDB发挥的优势越大。
优点：查询数据相对较快，适合大量的select，可以全文索引。
缺点：不支持事务，不支持外键，并发量较小，不适合大量update
InnoDB：
这种类型是事务安全的。.它与BDB类型具有相同的特性,它们还支持外键。InnoDB表格速度很快。具有比BDB还丰富的特性,因此如果
需要一个事务安全的存储引擎，建议使用它。在update时表进行行锁，并发量相对较大。
如果你的数据执行大量的INSERT或UPDATE，出于性能方面的考虑，应该使用InnoDB表。
优点：支持事务，支持外键，并发量较大，适合大量update
缺点：查询数据相对较快，不适合大量的select
对于支持事物的InnoDB类型的表，影响速度的主要原因是AUTOCOMMIT默认设置是打开的，而且程序没有显式调用BEGIN 开始事
务，导致每插入一条都自动Commit，严重影响了速度。可以在执行sql前调用begin，多条sql形成一个事物（即使autocommit打开也可以），将大大提高性能。
基本的差别为：MyISAM类型不支持事务处理等高级处理，而InnoDB类型支持。
MyISAM类型的表强调的是性能，其执行数度比InnoDB类型更快，但是不提供事务支持，而InnoDB提供事务支持以及外部键等高级数据库功能。
innodb和myisam更新比较：
innodb的数据组织就是按照主键建成的一个B+树，如果没有显示的定义主键，那么innodb会选一个not null unique key，作为主键，如果还是没有，
那么innodb会创建一个 6字节的主键，主键索引到
页不是具体行位置。不是递增的主键会使得插入的速度很慢，例如使用手机号或身份证号做为主键，所以善用AUTO_INCREMENT。
插入的速度和查询的速度有时候是不可调和的矛盾
说InnoDB不适合做count是不对的，MyISAM也是一样的慢，只不过MyISAM将正表的行数缓存起来，所以count整表很快，如果有查
询条件，并且不是主键查询，那就没有什么区别，主键count慢的原因是innodb是按照主键组织的，按照主键count的时候，会加载数据
InnoDB的页式存储会使得InnoDB更容易做整表缓存和热备份，如果表索引很多，那么InnoDB的更新速度要大于MyISAM，因为InnoDB的辅助索引关联的是表的主键，
是一个逻辑的值，而MyISAM的所有索引关联的是数据的物理位置，更新时有可能数据的物理位置发生变化，如果发生变化，那么所有的索引都要做更新
InnoDB 中不保存表的具体行数，也就是说，执行select count(*) from table时，InnoDB要扫描一遍整个表来计算有多少行，但是MyI
SAM只要简单的读出保存好的行数即可。注意的是，当count(*)语句包含 where条件时，两种表的操作是一样的。
