mysql的索引、事务、分库分表问题-编程知识

1.了解MySQL的索引吗？它为什么使用B+tree作为底层，而不是其他呢？

这里我们要谈的是其他数据结构的缺点，然后说说B+tree的优点，也就看你对MySQL的B+tree与其他数据结构熟不熟悉。

Hash

（1）Hash 索引仅仅能满足"=","IN"和"<=>"查询，不能使用范围查询。

由于 Hash 索引比较的是进行 Hash 运算之后的 Hash 值，所以它只能用于等值的过滤，不能用于基于范围的过滤，因为经过相应的 Hash 算法处理之后的 Hash 值的大小关系，并不能保证和Hash运算前完全一样。

（2）Hash 索引无法被用来数据的排序操作。

由于 Hash 索引中存放的是经过 Hash 计算之后的 Hash 值，而且Hash值的大小关系并不一定和 Hash 运算前的键值完全一样，所以数据库无法利用索引的数据来避免任何排序运算；

（3）Hash 索引不能利用部分索引键查询，即不适用最左前缀原则。

对于组合索引，Hash 索引在计算 Hash 值的时候是组合索引键合并后再一起计算 Hash 值，而不是单独计算 Hash 值，所以通过组合索引的前面一个或几个索引键进行查询的时候，Hash 索引也无法被利用。

（4）Hash 索引在任何时候都不能避免表扫描，不可使用覆盖索引。

前面已经知道，Hash 索引是将索引键通过 Hash 运算之后，将 Hash运算结果的 Hash 值和所对应的行指针信息存放于一个 Hash 表中，由于不同索引键存在相同 Hash 值，所以即使取满足某个 Hash 键值的数据的记录条数，也无法从 Hash 索引中直接完成查询，还是要通过访问表中的实际数据进行相应的比较，并得到相应的结果。
B-tree

每个节点占用一个盘块的磁盘空间，一个节点上有两个升序排序的关键字和三个指向子树根节点的指针，指针存储的是子节点所在磁盘块的地址。两个关键词划分成的三个范围域对应三个指针指向的子树的数据的范围域。以根节点为例，关键字为17和35，P1指针指向的子树的数据范围为小于17，P2指针指向的子树的数据范围为17~35，P3指针指向的子树的数据范围为大于35。
红黑树

红黑树（Red Black Tree）是一种自平衡二叉查找树。红黑树和AVL树类似，都是在进行插入和删除操作时通过特定操作保持二叉查找树的平衡，从而获得较高的查找性能。

它虽然是复杂的，但它的最坏情况运行时间也是非常良好的，并且在实践中是高效的：它可以在O(log n)时间内做查找，插入和删除，这里的n 是树中元素的数目
B+tree

B-Tree有许多变种，其中最常见的是B+Tree，例如MySQL就普遍使用B+Tree实现其索引结构。

与B-Tree相比，B+Tree有以下不同点：
1. 每个节点的指针上限为2d而不是2d+1。
2. 内节点不存储data，只存储key；叶子节点不存储指针。
由于B+Tree的非叶子节点只存储键值信息不再存储data数据，所有的data数据均存储在叶子节点中，这样使得内节点出度d值会变得大

由于并不是所有节点都具有相同的域，因此B+Tree中叶节点和内节点一般大小不同。这点与B-Tree不同，虽然B-Tree中不同节点存放的key和指针可能数量不一致，但是每个节点的域和上限是一致的，所以在实现中B-Tree往往对每个节点申请同等大小的空间。

带有顺序访问指针的B+Tree

一般在数据库系统或文件系统中使用的B+Tree结构都在经典B+Tree的基础上进行了优化，增加了顺序访问指针。在B+Tree的每个叶子节点增加一个指向相邻叶子节点的指针，就形成了带有顺序访问指针的B+Tree。做这个优化的目的是为了提高区间访问的性能，例如图中如果要查询key为从15到60的所有数据记录，当找到15后，只需顺着节点和指针顺序遍历就可以一次性访问到所有数据节点，极大提到了区间查询效率。

2.说说你理解的explain

这里我们只看重点需要记住的地方，同时这几点也是我们在做sql语句分析的时候，重点需要看的几个点：

1.type

这一列表示关联类型或访问类型，即MySQL决定如何查找表中的行，查找数据行记录的大概范围。依次从最优到最差分别为：system > const > eq_ref > ref > range > index > ALL 一般来说，得保证查询达到range级别，最好达到ref

NULL

mysql能够在优化阶段分解查询语句，在执行阶段用不着再访问表或索引。例如：在索引列中选取最小值，可以单独查找索引来完成，不需要在执行时访问表
```
explain select min(id) from tableName;
```
const, system

mysql能对查询的某部分进行优化并将其转化成一个常量（可以看show warnings 的结果）。用于 primary key 或 unique key 的所有列与常数比较时，所以表最多有一个匹配行，读取1次，速度比较快。system是const的特例，表里只有一条元组匹配时为system
```
 explain select * from (select * from tableName where id = 1) tableName;
```
eq_ref primary key 或 unique key 索引的所有部分被连接使用，最多只会返回一条符合条件的记录。这可能是在 const 之外最好的联接类型了，简单的 select 查询不会出现这种 type。
```
explain select * from tableName1 left join tableName2 on tableName1.id = tableName2.id;
```
ref

相比 eq_ref，不使用唯一索引，而是使用普通索引或者唯一性索引的部分前缀，索引要和某个值相比较，可能会找到多个符合条件的行。
1. 简单 select 查询，name是普通索引（非唯一索引）
```
explain select * from tableName where name = "starsky";
```
2. 关联表查询，idx_film_actor_id是film_id和actor_id的联合索引，这里使用到了film_actor的左边前缀film_id部分。
```
explain select film_id from film left join film_actor on film.id = film_actor.film_id;
```
range

范围扫描通常出现在 in(), between ,> ,<, >= 等操作中。使用一个索引来检索给定范围的行。
```
explain select * from actor where id > 1;
```
index

扫描全表索引，这通常比ALL快一些。（index是从索引中读取的，而all是从硬盘中读取）
```
explain select * from film;
```
ALL

即全表扫描，意味着mysql需要从头到尾去查找所需要的行。通常情况下这需要增加索引来进行优化了
```
explain select * from actor; 
```

2.possible_keys与key

possible_keys列

这一列显示查询可能使用哪些索引来查找。 explain 时可能出现 possible_keys 有列，而 key 显示 NULL 的情况，这种情况是因为表中数据不多，mysql认为索引对此查询帮助不大，选择了全表查询。如果该列是NULL，则没有相关的索引。在这种情况下，可以通过检查 where 子句看是否可以创造一个适当的索引来提高查询性能，然后用 explain 查看效果。
key列

这一列显示mysql实际采用哪个索引来优化对该表的访问。如果没有使用索引，则该列是 NULL。如果想强制mysql使用或忽视possible_keys列中的索引，在查询中使用 force index、ignore index。

3.extra

Using index

查询的列被索引覆盖，并且where筛选条件是索引的前导列，是性能高的表现。一般是使用了覆盖索引(索引包含了所有查询的字段)。对于innodb来说，如果是辅助索引性能会有不少提高
```
explain select film_id from film_actor where film_id = 1;
```
Using where

查询的列未被索引覆盖，where筛选条件非索引的前导列
```
explain select * from actor where name = 'a';
```
Using where Using index

查询的列被索引覆盖，并且where筛选条件是索引列之一但是不是索引的前导列，意味着无法直接通过索引查找来查询到符合条件的数据
```
explain select film_id from film_actor where actor_id = 1;
```
NULL

查询的列未被索引覆盖，并且where筛选条件是索引的前导列，意味着用到了索引，但是部分字段未被索引覆盖，必须通过“回表”来实现，不是纯粹地用到了索引，也不是完全没用到索引
```
explain select * from film_actor where film_id = 1;
```
Using index condition

与Using where类似，查询的列不完全被索引覆盖，where条件中是一个前导列的范围；
```
explain select * from film_actor where film_id > 1;
```
Using temporary

mysql需要创建一张临时表来处理查询。出现这种情况一般是要进行优化的，首先是想到用索引来优化。
1. actor.name没有索引，此时创建了张临时表来distinct
```
explain select distinct name from actor;
```
2. film.name建立了idx_name索引，此时查询时extra是using index,没有用临时表
```
explain select distinct name from film;
```
Using filesort

mysql 会对结果使用一个外部索引排序，而不是按索引次序从表里读取行。此时mysql会根据联接类型浏览所有符合条件的记录，并保存排序关键字和行指针，然后排序关键字并按顺序检索行信息。这种情况下一般也是要考虑使用索引来优化的。
actor.name未创建索引，会浏览actor整个表，保存排序关键字name和对应的id，然后排序name并检索行记录

explain select * from film order by name;

film.name建立了idx_name索引,此时查询时extra是using index
```
explain select * from actor order by name;
```

3.什么情况下设置了索引但无效

① 以“%”开头的LIKE语句，模糊匹配

② OR语句前后没有同时使用索引

③ 数据类型出现隐式转化（如varchar不加单引号的话可能会自动转换为int型）

4.说说分组查询与排序查询如何处理

GROUP BY
1. 为分组字段添加索引，使索引能够给出分组所需的数据
2. 语句查询不要过于复杂，减少查询的复杂度
ORDER BY
1. 在添加索引时，尽可能讲排序字段排在最左侧
2. 不要*查询，尽可能查询索引中有的字段

5.索引的目的是什么？索引对数据库系统的负面影响是什么？为数据表建立索引的原则有哪些？什么情况下不宜建立索引？

快速访问数据表中的特定信息，提高检索速度，创建唯一性索引，保证数据库表中每一行数据的唯一性。加速表和表之间的连接，使用分组和排序子句进行数据检索时，可以显著减少查询中分组和排序的时间
负面影响：创建索引和维护索引需要耗费时间，这个时间随着数据量的增加而增加；索引需要占用物理空间，不光是表需要占用数据空间，每个索引也需要占用物理空间；当对表进行增、删、改、的时候索引也要动态维护，这样就降低了数据的维护速度。
在最频繁使用的、用以缩小查询范围的字段上建立索引。在频繁使用的、需要排序的字段上建立索引
对于查询中很少涉及的列或者重复值比较多的列，不宜建立索引。对于一些特殊的数据类型，不宜建立索引，比如文本字段（text）等

6.简单描述mysql中，索引，主键，唯一索引，联合索引的区别，对数据库的性能有什么影响（从读写两方面）

索引是一种特殊的文件(InnoDB数据表上的索引是表空间的一个组成部分)，它们包含着对数据表里所有记录的引用指针。普通索引(由关键字KEY或INDEX定义的索引)的唯一任务是加快对数据的访问速度。普通索引允许被索引的数据列包含重复的值。如果能确定某个数据列将只包含彼此各不相同的值，在为这个数据列创建索引的时候就应该用关键字UNIQUE把它定义为一个唯一索引。也就是说，唯一索引可以保证数据记录的唯一性。主键，是一种特殊的唯一索引，在一张表中只能定义一个主键索引，主键用于唯一标识一条记录，使用关键字 PRIMARY KEY 来创建。索引可以覆盖多个数据列，如像INDEX(columnA, columnB)索引，这就是联合索引。索引可以极大的提高数据的查询速度，但是会降低插入、删除、更新表的速度，因为在执行这些写操作时，还要操作索引文件。

7.mysql事务的隔离级别,会有哪些问题?通常如何解决?项目中是否有修改过隔离级别，还有对MVCC的使用?

SET TRANSACTION ISOLATION LEVEL <隔离级别>;//设置隔离级别

mysql隔离级别分别是读取未提交,读取已提交,可重复读取,序列化（串行化）四个级别,相对的会产生的问题是脏读,不可重复读,幻读。对于脏读问题,通常出现在读取未提交隔离级别下,在事务2中会查询到事务1还未提交的数据,可以通过提高隔离级别的方式解决该问题,也可以给相应数据加锁解决，以下是加锁演示:

mysql> begin;
Query OK, 0 rows affected (0.00 sec)mysql> select * from products where id = 1 for update;
+----+------------+---------+-------+
| id | name       | price   | stock |
+----+------------+---------+-------+
|  1 | HUAWEI P40 | 3299.00 |   100 |
+----+------------+---------+-------+
1 row in set (0.00 sec)mysql> update products set stock = stock - 1 where id = 1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0mysql> commit;
Query OK, 0 rows affected (0.01 sec)

mysql> begin;
Query OK, 0 rows affected (0.00 sec)mysql> select * from products where id = 1 for update;
+----+------------+---------+-------+
| id | name       | price   | stock |
+----+------------+---------+-------+
|  1 | HUAWEI P40 | 3299.00 |    99 |
+----+------------+---------+-------+
1 row in set (12.87 sec)mysql> commit;
Query OK, 0 rows affected (0.00 sec)

可以看到的是事务依然是查询到了修改的数据,但是这并不属于脏读,而是mysql事务中查询语句加锁之后的当前磁盘数据读取,如果是未加锁的可能会是快照读取,读取的是事务开启前的数据。

不可重复读取:

对于不可重读读取,是在读取已提交的情况下,事务1修改了数据,并已经提交数据,此时按照事务的一致性特点,事务2是不能读取事务开启前不一样的数据的即,此时事务2只能读取到事务开启前的数据.要保证事务的一致性,我们需要提高事务的隔离级别到可重复读

幻读:

对于幻读问题,主要是在新增的数据情况下,事务1查询数据是否存在,不存在则新增数据,事务2一样查询数据是否存在,不存在则一样新增数据,因为mysql对于新增,修改,删除语句是默认加锁的,事务2必然会进入锁等待,等到事务1提交后会发现数据已存在导致数据新增失败,但是查询明明是不存在的,这就是幻读.这个问题我们可以通过将隔离级别提升到串行化解决，也可以给查询的数据加个间隙锁,即锁住一块区域的数据,使查询阶段就进入到锁等待,锁的查询会是磁盘此时实际的数据读取,事务1提交后是能够查询到数据的,这样就能够不去新增数据了。

下面是演示:

事务1:

mysql> begin;
Query OK, 0 rows affected (0.00 sec)mysql> select * from products where id > 1 and id < 10 for update;
+----+------------+----------+-------+
| id | name       | price    | stock |
+----+------------+----------+-------+
|  2 | HUAWEI P50 |  4999.00 |   100 |
|  3 | HUAWEI P60 | 10000.00 |   100 |
|  5 | HUAWEI P60 | 10000.00 |   100 |
+----+------------+----------+-------+
3 rows in set (0.00 sec)mysql> rollback;
Query OK, 0 rows affected (0.00 sec)

事务2:

mysql> begin;
Query OK, 0 rows affected (0.00 sec)mysql> select * from products where id > 1 and id < 10 for update;
+----+------------+----------+-------+
| id | name       | price    | stock |
+----+------------+----------+-------+
|  2 | HUAWEI P50 |  4999.00 |   100 |
|  3 | HUAWEI P60 | 10000.00 |   100 |
|  5 | HUAWEI P60 | 10000.00 |   100 |
+----+------------+----------+-------+
3 rows in set (48.11 sec)mysql> rollback;
Query OK, 0 rows affected (0.00 sec)

乐观锁的一种运用情况：MVCC

8.mysql都有什么锁，死锁判定原理和具体场景，死锁怎么解决?

MySQL有三种锁的级别：页级、表级、行级。

表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高,并发度最低。
行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。
页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般

死锁: 是指两个或两个以上的进程在执行过程中。因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等竺的进程称为死锁进程。

表级锁不会产生死锁.所以解决死锁主要还是针对于最常用的InnoDB。

死锁的关键在于：两个(或以上)的Session加锁的顺序不一致。

那么对应的解决死锁问题的关键就是：让不同的session加锁有次序。

死锁的解决办法?

1.查出的线程杀死 kill SELECT trx_MySQL_thread_id FROM information_schema.INNODB_TRX;

2.设置锁的超时时间 Innodb 行锁的等待时间，单位秒。可在会话级别设置，RDS 实例该参数的默认值为 50（秒）。

生产环境不推荐使用过大的 innodb_lock_wait_timeout参数值该参数支持在会话级别修改，方便应用在会话级别单独设置某些特殊操作的行锁等待超时时间，如下：

set innodb_lock_wait_timeout=1000; —设置当前会话 Innodb 行锁等待超时时间，单位秒。

9.水平分表与垂直分表

1.垂直切分

垂直切分常见有垂直分库和垂直分表两种。

垂直分库就是根据业务耦合性，将关联度低的不同表存储在不同的数据库。做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。与"微服务治理"的做法相似，每个微服务使用单独的一个数据库。如图：

垂直分表是基于数据库中的"列"进行，某个表字段较多，可以新建一张扩展表，将不经常用或字段长度较大的字段拆分出去到扩展表中。在字段很多的情况下（例如一个大表有100多个字段），通过"大表拆小表"，更便于开发与维护，也能避免跨页问题，MySQL底层是通过数据页存储的，一条记录占用空间过大会导致跨页，造成额外的性能开销。另外数据库以行为单位将数据加载到内存中，这样表中字段长度较短且访问频率较高，内存能加载更多的数据，命中率更高，减少了磁盘IO，从而提升了数据库性能。

垂直切分的优点：

解决业务系统层面的耦合，业务清晰
与微服务的治理类似，也能对不同业务的数据进行分级管理、维护、监控、扩展等
高并发场景下，垂直切分一定程度的提升IO、数据库连接数、单机硬件资源的瓶颈

缺点：

部分表无法join，只能通过接口聚合方式解决，提升了开发的复杂度
分布式事务处理复杂
依然存在单表数据量过大的问题（需要水平切分）

2.水平切分

当一个应用难以再细粒度的垂直切分，或切分后数据量行数巨大，存在单库读写、存储性能瓶颈，这时候就需要进行水平切分了。

水平切分分为库内分表和分库分表，是根据表内数据内在的逻辑关系，将同一个表按不同的条件分散到多个数据库或多个表中，每个表中只包含一部分数据，从而使得单个表的数据量变小，达到分布式的效果。如图所示：

库内分表只解决了单一表数据量过大的问题，但没有将表分布到不同机器的库上，因此对于减轻MySQL数据库的压力来说，帮助不是很大，大家还是竞争同一个物理机的CPU、内存、网络IO，最好通过分库分表来解决。

水平切分的优点：

不存在单库数据量过大、高并发的性能瓶颈，提升系统稳定性和负载能力
应用端改造较小，不需要拆分业务模块

缺点：

跨分片的事务一致性难以保证
跨库的join关联查询性能较差
数据多次扩展难度和维护量极大

10.你们那个xxxx项目的分库分表是根据什么规则做的呢？分完之后的处理做了哪些？

我们的项目是根据业务做了垂直的分库，将整个系统的分为了用户，商品，订单，其中我主要负责的是订单模块，在这里我对订单表根据hash取模处理去进行分表，具体是使用雪花算法去生成一个唯一的值之后进行hash的处理，随后在对分片数进行取模，当时我们是分了64张表，这里是对64取模。

在分表完成之后，我遇到了如下困难：

分表之后新库和老库的数据迁移问题
订单表数据的查询问题
日后业务增长之后，扩容的问题

对此我做了如下处理：

数据迁移问题
1. 导出老库中的数据，同时在业务中新库与老库同时写入新的订单数据
2. 配置mycat的分库分表规则
3. 通过mycat在系统的低峰期将数据导入到新库中，当时我们是千万的数据，时间大概在10-15分钟就完成了
4. 做数据验证，这里我们是通过在用户平时的查询中来做的，在用户查询的同时，会查询两个库的数据，去做对比，如果老库中的数据比新库多，会通过老库去补全新库的数据
查询问题

对于分库之后的连表查询问题，我们是采用了mycat去配置一个全局表，做数据的冗余，同时有创建一张异构索引表，记录用户的id以及用户的订单id，按照用户的id去进行hash取模分表，然后在用户查询数据的时候，先根据用户id查询出这个用户的订单id，然后在根据订单id去订单库查询数据
扩容问题

与前面的数据迁移一致，分库分表本质就是在做扩容，从一到多，从多到更多

11.主从原理

使用主从的原因:

实现服务器负载均衡

    即可以通过在主服务器和从服务器之间切分处理客户查询的负荷，从而得到更好的客户相应时间。通常情况下，数据库管理员会有两种思路。

       一是在主服务器上只实现数据的更新操作。包括数据记录的更新、删除、新建等等作业。而不关心数据的查询作业。数据库管理员将数据的查询请求全部转发到从服务器中。这在某些应用中会比较有用。如某些应用，像基金净值预测的网站。其数据的更新都是有管理员更新的，即更新的用户比较少。而查询的用户数量会非常的多。此时就可以设置一台主服务器，专门用来数据的更新。同时设置多台从服务器，用来负责用户信息的查询

       二是在主服务器上与从服务器切分查询的作业。在这种思路下，主服务器不单单要完成数据的更新、删除、插入等作业，同时也需要负担一部分查询作业。而从服务器的话，只负责数据的查询。当主服务器比较忙时，部分查询请求会自动发送到从服务器重，以降低主服务器的工作负荷。
通过复制实现数据的异地备份

可以定期的将数据从主服务器上复制到从服务器上，这无疑是先了数据的异地备份。在传统的备份体制下，是将数据备份在本地。此时备份作业与数据库服务器运行在同一台设备上，当备份作业运行时就会影响到服务器的正常运行。有时候会明显的降低服务器的性能。同时，将备份数据存放在本地，也不是很安全。如硬盘因为电压等原因被损坏或者服务器被失窃，此时由于备份文件仍然存放在硬盘上，数据库管理员无法使用备份文件来恢复数据。这显然会给企业带来比较大的损失。
提高数据库系统的可用性

    数据库复制功能实现了主服务器与从服务器之间数据的同步，增加了数据库系统的可用性。当主服务器出现问题时，数据库管理员可以马上让从服务器作为主服务器，用来数据的更新与查询服务。然后回过头来再仔细的检查主服务器的问题。此时一般数据库管理员也会采用两种手段。

       一是主服务器故障之后，虽然从服务器取代了主服务器的位置，但是对于主服务器可以采取的操作仍然做了一些限制。如仍然只能够进行数据的查询，而不能够进行数据的更新、删除等操作。这主要是从数据的安全性考虑。如现在一些银行系统的升级，在升级的过程中，只能够查询余额而不能够取钱。这是同样的道理。

       二是从服务器真正变成了主服务器。当从服务器切换为主服务器之后，其地位完全与原先的主服务器相同。此时可以实现对数据的查询、更新、删除等操作。为此就需要做好数据的安全性工作。即数据的安全策略，要与原先的主服务器完全相同。否则的话，就可能会留下一定的安全隐患

原理：

master服务器将数据的改变都记录到二进制binlog日志中，只要master上的数据发生改变，则将其改变写入二进制日志；
salve服务器会在一定时间间隔内对master二进制日志进行探测其是否发生改变，如果发生改变，则开始一个I/O Thread请求master二进制日志
同时主节点为每个I/O线程启动一个dump线程，用于向其发送二进制日志，并保存至从节点本地的中继日志中
从节点将启动SQL线程从中继日志中读取二进制日志，在本地重放，使得其数据和主节点的保持一致
最后I/O Thread和SQL Thread将进入睡眠状态，等待下一次被唤醒.

需要理解：

1）从库会生成两个线程,一个I/O线程,一个SQL线程;

2）I/O线程会去请求主库的binlog,并将得到的binlog写到本地的relay-log(中继日志)文件中;*

3）主库会生成一个log dump线程,用来给从库I/O线程传binlog;

4）SQL线程,会读取relay log文件中的日志,并解析成sql语句逐一执行;

复制流程：
1. master将操作语句记录到binlog日志中
2. salve服务器会在一定时间间隔内对master二进制日志进行探测其是否发生改变，如果发生改变
3. salave开启两个线程：IO线程和SQL线程
  
  1）*IO线程：*负责读取master的binlog内容到中继日志relay log里；
  
  2）*SQL线程：*负责从relay log日志里读出binlog内容，并更新到slave的数据库里（保证数据一致）

12.主从延迟

2、说说自己对于 MySQL 常见的两种存储引擎：MyISAM与InnoDB的理解？

InnoDB 引擎：InnoDB 引擎提供了对数据库 acid 事务的支持，并且还提供了行级锁和外键的约束，它的设计的目标就是处理大数据容量的数据库系统。MySQL 运行的时候，InnoDB 会在内存中建立缓冲池，用于缓冲数据和索引。但是该引擎是不支持全文搜索，同时启动也比较的慢，它是不会保存表的行数的，所以当进行 select count() from table 指令的时候，需要进行扫描全表。由于锁的粒度小，写操作是不会锁定全表的,所以在并发度较高的场景下使用会提升效率的。

MyIASM 引擎：MySQL 的默认引擎，但不提供事务的支持，也不支持行级锁和外键。因此当执行插入和更新语句时，即执行写操作的时候需要锁定这个表，所以会导致效率会降低。不过和 InnoDB 不同的是，MyIASM 引擎是保存了表的行数，于是当进行 select count() from table 语句时，可以直接的读取已经保存的值而不需要进行扫描全表。所以，如果表的读操作远远多于写操作时，并且不需要事务的支持的，可以将 MyIASM 作为数据库引擎的首选。