MySQL原理:存储引擎、索引和事务

一、存储引擎

MySQL里的存储引擎，“存储”指的是存储数据，“引擎”是发动机的核心部分,习惯上常用引擎来代指发动机，这里指数据库的核心。

简单来说，存储引擎就是数据的存储结构，由实际业务决定。

MySQL常见的四种存储引擎：

1.MyISAM

不支持事务，支持全文索引，不支持外键，B+树，表锁，对于一些在线分析处理操作速度快。数据和索引分离。

文件组成由 myd  存放数据的  myi存放索引的

2.InnoDB

支持事务，不支持全文索引，支持外键，B+树，行锁，主要是面向在线事务处理方面的应用，特点是行锁设计，并支持外键。Innodb采用聚集索引的方式。没有主键，没有唯一键，为每一行生产一个6字节的行id,作为主键。索引当作数据的一部分存储。

3.Memory

将数据放在内存中，如果数据库重启或者宕机，表数据就会丢失。非常适合存储一些临时表，默认的是哈希索引，不是B+树索引，varchar()默认是按照char()存储的，浪费内存。

不支持text和BLOB类型。varchar当成char类型处理。如果数据中有text和BLOB类型，数据库会把这些数字转换到磁盘上。

4.Archive

只支持INSERT和SELECT操作，一般用于日志处理，使用压缩算法将数据进行压缩后存储，压缩比例一般是1:10，主要提供插入和压缩功能。

二、索引

关于MySQL索引的好处，如果把正确合理设计并且使用索引的MySQL比作是一辆兰博基尼的话，那么没有设计和使用索引的MySQL就是一个人力三轮车。对于没有索引的表，单表查询可能几十万数据就是瓶颈，而通常大型网站单日就可能会产生几十万甚至几百万的数据，没有索引查询会变的非常缓慢。其多个数据表都会对经常被查询的字段添加索引

MySQL索引的概念

索引是一种特殊的文件(InnoDB数据表上的索引是表空间的一个组成部分)，它们包含着对数据表里所有记录的引用指针。更通俗的说，数据库索引好比是一本书前面的目录，能加快数据库的查询速度。在没有索引的情况下，数据库会遍历全部200条数据后选择符合条件的；而有了相应的索引之后，数据库会直接在索引中查找符合条件的选项。如果我们把SQL语句换成“SELECT * FROM article WHERE id=2000000”，那么你是希望数据库按照顺序读取完200万行数据以后给你结果还是直接在索引中定位呢？（一般数据库默认都会为主键生成索引）。

索引分为聚簇索引和非聚簇索引两种，聚簇索引是按照数据存放的物理位置为顺序的，而非聚簇索引就不一样了；聚簇索引能提高多行检索的速度，而非聚簇索引对于单行的检索很快。

MySQL索引的类型

1. 普通索引

这是最基本的索引，它没有任何限制， MyIASM中默认的BTREE类型的索引，也是我们大多数情况下用到的索引。

01	–直接创建索引
02	CREATE INDEX index_name ON table(column(length))

 

03	–修改表结构的方式添加索引
04	ALTER TABLE table_name ADD INDEX index_name ON (column(length))

 

05	–创建表的时候同时创建索引
06	CREATE TABLE `table` (

 

07		`id` int(11) NOT NULL AUTO_INCREMENT ,
08	`title` char(255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ,

 

09	`content` text CHARACTER SET utf8 COLLATE utf8_general_ci NULL ,
10	`time` int(10) NULL DEFAULT NULL ,

 

11	PRIMARY KEY (`id`),
12	INDEX index_name (title(length))

 

13	)
14	–删除索引

 

15	DROP INDEX index_name ON table

2. 唯一索引

与普通索引类似，不同的就是：索引列的值必须唯一，但允许有空值（注意和主键不同）。如果是组合索引，则列值的组合必须唯一，创建方法和普通索引类似。

01	–创建唯一索引
02	CREATE UNIQUE INDEX indexName ON table(column(length))

 

03	–修改表结构
04	ALTER TABLE table_name ADD UNIQUE indexName ON (column(length))

 

05	–创建表的时候直接指定
06	CREATE TABLE `table` (

 

07		`id` int(11) NOT NULL AUTO_INCREMENT ,
08	`title` char(255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ,

 

09	`content` text CHARACTER SET utf8 COLLATE utf8_general_ci NULL ,
10	`time` int(10) NULL DEFAULT NULL ,

 

11	PRIMARY KEY (`id`),
12	UNIQUE indexName (title(length))

 

13

);

3. 全文索引（FULLTEXT）

MySQL从3.23.23版开始支持全文索引和全文检索，FULLTEXT索引仅可用于 MyISAM 表；他们可以从CHAR、VARCHAR或TEXT列中作为CREATE TABLE语句的一部分被创建，或是随后使用ALTER TABLE 或CREATE INDEX被添加。对于较大的数据集，将你的资料输入一个没有FULLTEXT索引的表中，然后创建索引，其速度比把资料输入现有FULLTEXT索引的速度更为快。不过切记对于大容量的数据表，生成全文索引是一个非常消耗时间非常消耗硬盘空间的做法。

01	–创建表的适合添加全文索引
02	CREATE TABLE `table` (

 

03		`id` int(11) NOT NULL AUTO_INCREMENT ,
04	`title` char(255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ,

 

05	`content` text CHARACTER SET utf8 COLLATE utf8_general_ci NULL ,
06	`time` int(10) NULL DEFAULT NULL ,

 

07	PRIMARY KEY (`id`),
08	FULLTEXT (content)

 

09	);
10	–修改表结构添加全文索引

 

11	ALTER TABLE article ADD FULLTEXT index_content(content)
12	–直接创建索引

 

13	CREATE FULLTEXT INDEX index_content ON article(content)

4. 单列索引、多列索引

多个单列索引与单个多列索引的查询效果不同，因为执行查询时，MySQL只能使用一个索引，会从多个索引中选择一个限制最为严格的索引。

5. 组合索引（最左前缀）

平时用的SQL查询语句一般都有比较多的限制条件，所以为了进一步榨取MySQL的效率，就要考虑建立组合索引。例如上表中针对title和time建立一个组合索引：ALTER TABLE article ADD INDEX index_titme_time (title(50),time(10))。建立这样的组合索引，其实是相当于分别建立了下面两组组合索引：

–title,time

–title

为什么没有time这样的组合索引呢？这是因为MySQL组合索引“最左前缀”的结果。简单的理解就是只从最左面的开始组合。并不是只要包含这两列的查询都会用到该组合索引，如下面的几个SQL所示：

1	–使用到上面的索引
2	SELECT * FROM article WHREE title='测试' AND time=1234567890;

 

3	SELECT * FROM article WHREE utitle='测试';
4	–不使用上面的索引

 

5	SELECT * FROM article WHREE time=1234567890;

MySQL索引的优化

上面都在说使用索引的好处，但过多的使用索引将会造成滥用。因此索引也会有它的缺点：虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件。建立索引会占用磁盘空间的索引文件。一般情况这个问题不太严重，但如果你在一个大表上创建了多种组合索引，索引文件的会膨胀很快。索引只是提高效率的一个因素，如果你的MySQL有大数据量的表，就需要花时间研究建立最优秀的索引，或优化查询语句。下面是一些总结以及收藏的MySQL索引的注意事项和优化方法。

1. 何时使用聚集索引或非聚集索引？

动作描述	使用聚集索引	使用非聚集索引
列经常被分组排序	使用	使用
返回某范围内的数据	使用	不使用
一个或极少不同值	不使用	不使用
小数目的不同值	使用	不使用
大数目的不同值	不使用	使用
频繁更新的列	不使用	使用
外键列	使用	使用
主键列	使用	使用
频繁修改索引列	不使用	使用

事实上，我们可以通过前面聚集索引和非聚集索引的定义的例子来理解上表。如：返回某范围内的数据一项。比如您的某个表有一个时间列，恰好您把聚合索引建立在了该列，这时您查询2004年1月1日至2004年10月1日之间的全部数据时，这个速度就将是很快的，因为您的这本字典正文是按日期进行排序的，聚类索引只需要找到要检索的所有数据中的开头和结尾数据即可；而不像非聚集索引，必须先查到目录中查到每一项数据对应的页码，然后再根据页码查到具体内容。其实这个具体用法我还不是很理解，只能等待后期的项目开发中慢慢学学了。

2. 索引不会包含有NULL值的列

只要列中包含有NULL值都将不会被包含在索引中，复合索引中只要有一列含有NULL值，那么这一列对于此复合索引就是无效的。所以我们在数据库设计时不要让字段的默认值为NULL。

3. 使用短索引

对串列进行索引，如果可能应该指定一个前缀长度。例如，如果有一个CHAR(255)的列，如果在前10个或20个字符内，多数值是惟一的，那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。

4. 索引列排序

MySQL查询只使用一个索引，因此如果where子句中已经使用了索引的话，那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序操作；尽量不要包含多个列的排序，如果需要最好给这些列创建复合索引。

5. like语句操作

一般情况下不鼓励使用like操作，如果非使用不可，如何使用也是一个问题。like “%aaa%” 不会使用索引而like “aaa%”可以使用索引。

6. 不要在列上进行运算

例如：select * from users where YEAR(adddate)<2007，将在每个行上进行运算，这将导致索引失效而进行全表扫描，因此我们可以改成：select * from users where adddate<’2007-01-01′。

 

 

三. 事务

事务由单独单元的一个或多个SQL语句组成，在这个单元中，每个MySQL语句是相互依赖的。而整个单独单元作为一个不可分割的整体，如果单元中某条SQL语句一旦执行失败或产生错误，整个单元将会回滚。所有受到影响的数据将返回到事物开始以前的状态；如果单元中的所有SQL语句均执行成功，则事物被顺利执行。

InnoDB的事务

严格上来说，事务必须同时满足4个特性，即通常所说事务的ACID特性。虽然理论上定义了严格的事务要求，但是数据库厂商出于各种目的并没有严格满足事务的ACID标准。例如，对于MYSQL的NDB Cluster引擎，虽然支持事务，但是不满足D的要求，即持久性的要求。对于Oracle数据库来说，其默认的事务隔离级别为READ COMMITTED，不满足I的要求，即隔离性的要求。对于InnoDB存储引擎而言，默认的事务隔离级别是READ REPRATABLE，完全遵循和满足事务的ACID特性。

事务的ACID

1. A(atomicity) 原子性。一个事务的执行被视为一个不可分割的最小单元。事务里面的操作，要么全部成功执行，要么全部失败回滚，不可以只执行其中的一部分。

2. C(consistency) 一致性。一个事务的执行不应该破坏数据库的完整性约束。如果上述例子中第2个操作执行后系统崩溃，保证A和B的金钱总计是不会变的。

3. I(isolation) 隔离性。通常来说，事务之间的行为不应该互相影响。然而实际情况中，事务相互影响的程度受到隔离级别的影响。

4. D(durability) 持久性。事务提交之后，需要将提交的事务持久化到磁盘。即使系统崩溃，提交的数据也不应该丢失。

3.4、事务不隔离会产生什么问题

1）第一类丢失更新：在没有事务隔离的情况下，两个事务都同时更新一行数据，但是第二个事务却中途失败退出， 导致对数据的两个修改都失效了。

例如：

张三的工资为5000，事务A中获取工资为5000，事务B获取工资为5000，汇入100，并提交数据库，工资变为5100，随后，事务A发生异常，回滚了，恢复张三的工资为5000，这样就导致事务B的更新丢失了。

2）脏读：脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。

例如：

　　张三的工资为5000,事务A中把他的工资改为8000,但事务A尚未提交。

　　与此同时，

　　事务B正在读取张三的工资，读取到张三的工资为8000。

　　随后，

　　事务A发生异常，而回滚了事务。张三的工资又回滚为5000。

　　最后，

　　事务B读取到的张三工资为8000的数据即为脏数据，事务B做了一次脏读。

3）不可重复读：是指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。

例如：

　　在事务A中，读取到张三的工资为5000，操作没有完成，事务还没提交。

　　与此同时，

　　事务B把张三的工资改为8000，并提交了事务。

　　随后，

　　在事务A中，再次读取张三的工资，此时工资变为8000。在一个事务中前后两次读取的结果并不致，导致了不可重复读。

4）第二类丢失更新：不可重复读的特例。有两个并发事务同时读取同一行数据，然后其中一个对它进行修改提交，而另一个也进行了修改提交。这就会造成第一次写操作失效。

例如：

在事务A中，读取到张三的存款为5000，操作没有完成，事务还没提交。

　　与此同时，

　　事务B，存储1000，把张三的存款改为6000，并提交了事务。

　　随后，

　　在事务A中，存储500，把张三的存款改为5500，并提交了事务，这样事务A的更新覆盖了事务B的更新。

5）幻读：是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样。

例如：

　　目前工资为5000的员工有10人，事务A读取所有工资为5000的人数为10人。

　　此时，

　　事务B插入一条工资也为5000的记录。

　　这是，事务A再次读取工资为5000的员工，记录为11人。此时产生了幻读。

提醒：

不可重复读的重点是修改，同样的条件，你读取过的数据，再次读取出来发现值不一样了。

幻读的重点在于新增或者删除，同样的条件，第 1 次和第 2 次读出来的记录数不一样。

 

1. READ UNCOMMITTED(未提交读)。在RU的隔离级别下，事务A对数据做的修改，即使没有提交，对于事务B来说也是可见的，这种问题叫脏读。这是隔离程度较低的一种隔离级别，在实际运用中会引起很多问题，因此一般不常用。

1. READ COMMITTED(提交读)。在RC的隔离级别下，不会出现脏读的问题。事务A对数据做的修改，提交之后会对事务B可见，举例，事务B开启时读到数据1，接下来事务A开启，把这个数据改成2，提交，B再次读取这个数据，会读到最新的数据2。在RC的隔离级别下，会出现不可重复读的问题。这个隔离级别是许多数据库的默认隔离级别。

1. REPEATABLE READ(可重复读)。在RR的隔离级别下，不会出现不可重复读的问题。事务A对数据做的修改，提交之后，对于先于事务A开启的事务是不可见的。举例，事务B开启时读到数据1，接下来事务A开启，把这个数据改成2，提交，B再次读取这个数据，仍然只能读到1。在RR的隔离级别下，会出现幻读的问题。幻读的意思是，当某个事务在读取某个范围内的值的时候，另外一个事务在这个范围内插入了新记录，那么之前的事务再次读取这个范围的值，会读取到新插入的数据。Mysql默认的隔离级别是RR，然而mysql的innoDB引擎间隙锁成功解决了幻读的问题。

1. SERIALIZABLE(可串行化)。可串行化是最高的隔离级别。这种隔离级别强制要求所有事物串行执行，在这种隔离级别下，读取的每行数据都加锁，会导致大量的锁征用问题，性能最差。

1. 
    

查询默认的隔离级别 ：select @@tx_isolation;

 

第一个小人，可能读到1-20之间的任何一个。因为未提交读的隔离级别下，其他事务对数据的修改也是对当前事务可见的。第二个小人可能读到1，10和20，他只能读到其他事务已经提交了的数据。第三个小人读到的数据去决于自身事务开启的时间点。在事务开启时，读到的是多少，那么在事务提交之前读到的值就是多少。第四个小人，只有在A end 到B start之间开启，才有可能读到数据，而在事务A和事务B执行的期间是读不到数据的。因为第四小人读数据是需要加锁的，事务A和B执行期间，会占用数据的写锁，导致第四个小人等待锁。

事务的实现是基于数据库的存储引擎。不同的存储引擎对事务的支持程度不一样。mysql中支持事务的存储引擎有innoDB和NDB。innoDB是mysql默认的存储引擎，默认的隔离级别是RR，并且在RR的隔离级别下更进一步，通过多版本并发控制（MVCC，Multiversion Concurrency Control ）解决不可重复读问题，加上间隙锁（也就是并发控制）解决幻读问题。因此innoDB的RR隔离级别其实实现了串行化级别的效果，而且保留了比较好的并发性能。

事务的隔离性是通过锁实现，而事务的原子性、一致性和持久性则是通过事务日志实现。说到事务日志，不得不说的就是redo和undo。

1.redo log

在innoDB的存储引擎中，事务日志通过重做(redo)日志和innoDB存储引擎的日志缓冲(InnoDB Log Buffer)实现。事务开启时，事务中的操作，都会先写入存储引擎的日志缓冲中，在事务提交之前，这些缓冲的日志都需要提前刷新到磁盘上持久化，这就是DBA们口中常说的“日志先行”(Write-Ahead Logging)。当事务提交之后，在Buffer Pool中映射的数据文件才会慢慢刷新到磁盘。此时如果数据库崩溃或者宕机，那么当系统重启进行恢复时，就可以根据redo log中记录的日志，把数据库恢复到崩溃前的一个状态。未完成的事务，可以继续提交，也可以选择回滚，这基于恢复的策略而定。

在系统启动的时候，就已经为redo log分配了一块连续的存储空间,以顺序追加的方式记录Redo Log,通过顺序IO来改善性能。所有的事务共享redo log的存储空间，它们的Redo Log按语句的执行顺序，依次交替的记录在一起。如下一个简单示例：

记录1：

记录2：

记录3：

记录4：

记录5：

2.undo log

undo log主要为事务的回滚服务。在事务执行的过程中，除了记录redo log，还会记录一定量的undo log。undo log记录了数据在每个操作前的状态，如果事务执行过程中需要回滚，就可以根据undo log进行回滚操作。单个事务的回滚，只会回滚当前事务做的操作，并不会影响到其他的事务做的操作。

以下是undo+redo事务的简化过程

假设有2个数值，分别为A和B,值为1，2

1. start transaction;

2. 记录 A=1 到undo log;

3. update A = 3；

4. 记录 A=3 到redo log；

5. 记录 B=2 到undo log；

6. update B = 4；

7. 记录B = 4 到redo log；

8. 将redo log刷新到磁盘

9. commit

在1-8的任意一步系统宕机，事务未提交，该事务就不会对磁盘上的数据做任何影响。如果在8-9之间宕机，恢复之后可以选择回滚，也可以选择继续完成事务提交，因为此时redo log已经持久化。若在9之后系统宕机，内存映射中变更的数据还来不及刷回磁盘，那么系统恢复之后，可以根据redo log把数据刷回磁盘。

所以，redo log其实保障的是事务的持久性和一致性，而undo log则保障了事务的原子性。

伪事务（锁定）

1、在MySQL中根据不同的需求，提供了很多存储引擎，但是有的存储引擎不支持事务，对于这种情况，可以使用表锁定来代替事务。

2、对于不支持事务的存储引擎MYISAM类型数据表，当用户插入，修改，删除时，这些操作都会立即保存到磁盘中，当多用户同时操作某个表时，可以使用表锁定来避免同一时间有多个用户对数据库中指定表进行操作，这样可以避免在用户操作数据表过程中受到干扰。只有但用户释放表的操作锁定后，其他 用户才可以访问这些修改的数据表。