2021最新Java面经整理 | 数据库篇（一）MySQL

客官°小女子只卖身不卖艺 2022-12-20 05:58 240阅读 0赞

**目录**

一、基础

1、数据库范式

2、视图

3、游标

4、存储过程与函数

5、触发器

6、常用问题

二、事务

1、事务四大特性（ACID）

2、脏读、不可重复读、幻读

3、事务隔离级别

三、索引

1、啥是索引

2、索引的分类

3、索引的实现方式

4、索引的基本原理

5、索引的创建原则

6、百万级别或以上的数据如何删除？

7、B树和B+树的区别

8、Hash索引和B+树所有有什么区别或者说优劣呢?

9、数据库为什么使用B+树而不是B树？

10、什么是聚簇索引？何时使用聚簇索引与非聚簇索引？

11、非聚簇索引一定会回表查询吗？

12、联合索引是什么？为什么需要注意联合索引中的顺序？

四、MySQL 存储引擎

1、MyISAM

2、InnoDB

3、MEMORY

4、三种存储引擎的特点

5、MyISAM和InnoDB区别

五、锁

1、锁分类

2、隔离级别与锁的关系

3、死锁

4、乐观锁和悲观锁

5、MySQL中InnoDB引擎的行锁是怎么实现的？

6、MVCC 锁并发

六、SQL的生命周期

七、SQL优化

1、关心过业务系统里面的sql耗时吗？统计过慢查询吗？对慢查询都怎么优化过？

2、优化查询过程中的数据访问

3、优化长难的查询语句

4、优化特定类型的查询语句

5、优化关联查询

6、优化子查询

7、优化LIMIT分页

8、优化UNION查询

9、优化WHERE子句

八、数据库优化

1、数据库结构优化

2、大表数据查询，怎么优化

3、超大分页怎么处理？

4、慢查询日志

5、MySQL数据库cpu飙升到500%的话他怎么处理？

6、大表怎么优化？某个表有近千万数据，CRUD比较慢，如何优化？分库分表了是怎么做的？分表分库了有什么问题？有用到中间件么？他们的原理知道么？

九、分库分表（一）

1、垂直拆分

2、水平拆分

3、数据库分片的两种常见方案

4、分库分表后面临的问题

九、分库分表（二）

1、数据切分

2、垂直切分

3、水平切分（重点）

4、数据切分导致的一些问题

5、数据源管理的问题

6、分布式事务的解决方案

十、主从复制、读写分离

1、主从复制

2、读写分离有哪些解决方案？

十、其他问题

1、MySQL有关权限的表都有哪几个

2、MySQL的binlog有有几种录入格式？分别有什么区别？

3、MyISAM与InnoDB区别

4、MyISAM索引与InnoDB索引的区别？

5、为什么要尽量设定一个主键？

6、主键使用自增ID还是UUID？

7、字段为什么要求定义为not null？

8、如果要存储用户的密码散列，应该使用什么字段进行存储？

9、索引是个什么样的数据结构呢?

10、Hash索引和B+树所有有什么区别或者说优劣呢?

11、上面提到了B+树在满足聚簇索引和覆盖索引的时候不需要回表查询数据,什么是聚簇索引?

12、非聚簇索引一定会回表查询吗?

13、在建立索引的时候,都有哪些需要考虑的因素呢?

14、联合索引是什么?为什么需要注意联合索引中的顺序?

15、创建的索引有没有被使用到?或者说怎么才可以知道这条语句运行很慢的原因?

16、那么在哪些情况下会发生针对该列创建了索引但是在查询的时候并没有使用呢?

16、同时有多个事务在进行会怎么样呢?

17、Innodb使用的是哪种隔离级别呢?

18、关于MVVC

19、在MVCC并发控制中，读操作可以分成两类：

20、哈希索引的优势

21、哈希索引不适用的场景

22、什么是表分区？

23、表分区与分表的区别

24、表分区有什么好处？

25、分区表的限制因素

26、如何判断当前MySQL是否支持分区？

27、MySQL支持的分区类型有哪些？

28、行级锁定的优点：

29、行级锁定的缺点：

30、MySQL优化

31、key和index的区别

32、数据库表创建注意事项

--------------------

## 一、基础 ##

### 1、数据库范式 ###

*  第一范式：1NF是对属性的原子性约束，要求字段具有原子性，不可再分解 (只要是关系型数据库都满足1NF)。
 *  第二范式：2NF是在满足第一范式的前提下，非主键字段不能出现部分依赖主键；解决：消除复合主键就可避免出现部分以来，可增加单列关键字。
 *  第三范式：3NF是在满足第二范式的前提下，非主键字段不能出现传递依赖，比如某个字段a依赖于主键，而一些字段依赖字段a，这就是传递依赖。解决：将一个实体信息的数据放在一个表内实现。

### 2、视图 ###

**1）什么是视图？**

为了提高复杂SQL语句的复用性和表操作的安全性，MySQL数据库管理系统提供了视图特性。所谓视图，本质上是一种虚拟表，在物理上是不存在的，其内容与真实的表相似，包含一系列带有名称的列和行数据。但是，视图并不在数据库中以储存的数据值形式存在。行和列数据来自定义视图的查询所引用基本表，并且在具体引用视图时动态生成。

视图使开发者只关心感兴趣的某些特定数据和所负责的特定任务，只能看到视图中所定义的数据，而不是视图所引用表中的数据，从而提高了数据库中数据的安全性。

视图的特点如下:

*  视图的列可以来自不同的表，是表的抽象和在逻辑意义上建立的新关系。
 *  视图是由基本表(实表)产生的表(虚表)。
 *  视图的建立和删除不影响基本表。
 *  对视图内容的更新(添加，删除和修改)直接影响基本表。
 *  当视图来自多个基本表时，不允许添加和删除数据。

视图的操作包括创建视图，查看视图，删除视图和修改视图。

**2）视图的使用场景有哪些？**

视图根本用途：简化sql查询，提高开发效率。如果说还有另外一个用途那就是兼容老的表结构。

下面是视图的常见使用场景：

*  重用SQL语句；
 *  简化复杂的SQL操作。在编写查询后，可以方便的重用它而不必知道它的基本查询细节；
 *  使用表的组成部分而不是整个表；
 *  保护数据。可以给用户授予表的特定部分的访问权限而不是整个表的访问权限；
 *  更改数据格式和表示。视图可返回与底层表的表示和格式不同的数据。

**3）视图的优点**

*  查询简单化。视图能简化用户的操作
 *  数据安全性。视图使用户能以多种角度看待同一数据，能够对机密数据提供安全保护
 *  逻辑数据独立性。视图对重构数据库提供了一定程度的逻辑独立性

**4）视图的缺点**

*  性能。数据库必须把视图的查询转化成对基本表的查询，如果这个视图是由一个复杂的多表查询所定义，那么，即使是视图的一个简单查询，数据库也把它变成一个复杂的结合体，需要花费一定的时间。
 *  修改限制。当用户试图修改视图的某些行时，数据库必须把它转化为对基本表的某些行的修改。事实上，当从视图中插入或者删除时，情况也是这样。对于简单视图来说，这是很方便的，但是，对于比较复杂的视图，可能是不可修改的。这些视图有如下特征：1.有UNIQUE等集合操作符的视图。2.有GROUP BY子句的视图。3.有诸如AVG\\SUM\\MAX等聚合函数的视图。 4.使用DISTINCT关键字的视图。5.连接表的视图（其中有些例外）

### 3、游标 ###

游标是系统为用户开设的一个数据缓冲区，存放SQL语句的执行结果，每个游标区都有一个名字。用户可以通过游标逐一获取记录并赋给主变量，交由主语言进一步处理。

### 4、存储过程与函数 ###

**1）什么是存储过程？**

存储过程是一个预编译的SQL语句，优点是允许模块化的设计，就是说只需要创建一次，以后在该程序中就可以调用多次。如果某次操作需要执行多次SQL，使用存储过程比单纯SQL语句执行要快。

**优点：**

*  1）存储过程是预编译过的，执行效率高。
 *  2）存储过程的代码直接存放于数据库中，通过存储过程名直接调用，减少网络通讯。
 *  3）安全性高，执行存储过程需要有一定权限的用户。
 *  4）存储过程可以重复使用，减少数据库开发人员的工作量。

**缺点：**

*  1）调试麻烦，但是用 PL/SQL Developer 调试很方便！弥补这个缺点。
 *  2）移植问题，数据库端代码当然是与数据库相关的。但是如果是做工程型项目，基本不存在移植问题。
 *  3）重新编译问题，因为后端代码是运行前编译的，如果带有引用关系的对象发生改变时，受影响的存储过程、包将需要重新编译（不过也可以设置成运行时刻自动编译）。
 *  4）如果在一个程序系统中大量的使用存储过程，到程序交付使用的时候随着用户需求的增加会导致数据结构的变化，接着就是系统的相关问题了，最后如果用户想维护该系统可以说是很难很难、而且代价是空前的，维护起来更麻烦。

### 5、触发器 ###

**1）什么是触发器？触发器的使用场景有哪些**？

触发器是用户定义在关系表上的一类由事件驱动的特殊的存储过程。触发器是指一段代码，当触发某个事件时，自动执行这些代码。

使用场景：

*  可以通过数据库中的相关表实现级联更改。
 *  实时监控某张表中的某个字段的更改而需要做出相应的处理。
 *  例如可以生成某些业务的编号。
 *  注意不要滥用，否则会造成数据库及应用程序的维护困难。
 *  大家需要牢记以上基础知识点，重点是理解数据类型CHAR和VARCHAR的差异，表存储引擎InnoDB和MyISAM的区别。

**2）MySQL中都有哪些触发器？**

在MySQL数据库中有如下六种触发器：

*  Before Insert
 *  After Insert
 *  Before Update
 *  After Update
 *  Before Delete
 *  After Delete

### **6、常用问题** ###

**1）SQL语句主要分为哪几类**

*  数据定义语言DDL（Data Ddefinition Language）CREATE，DROP，ALTER。主要为以上操作 即对逻辑结构等有操作的，其中包括表结构，视图和索引。
 *  数据查询语言DQL（Data Query Language）SELECT。这个较为好理解 即查询操作，以select关键字。各种简单查询，连接查询等 都属于DQL。
 *  数据操纵语言DML（Data Manipulation Language）INSERT，UPDATE，DELETE。主要为以上操作 即对数据进行操作的，对应上面所说的查询操作 DQL与DML共同构建了多数初级程序员常用的增删改查操作。而查询是较为特殊的一种 被划分到DQL中。
 *  数据控制功能DCL（Data Control Language）GRANT，REVOKE，COMMIT，ROLLBACK。主要为以上操作 即对数据库安全性完整性等有操作的，可以简单的理解为权限控制等。

**2）超键、候选键、主键、外键分别是什么？**

*  超键：在关系中能唯一标识元组的属性集称为关系模式的超键。一个属性可以为作为一个超键，多个属性组合在一起也可以作为一个超键。超键包含候选键和主键。
 *  候选键：是最小超键，即没有冗余元素的超键。
 *  主键：数据库表中对储存数据对象予以唯一和完整标识的数据列或属性的组合。一个数据列只能有一个主键，且主键的取值不能缺失，即不能为空值（Null）。
 *  外键：在一个表中存在的另一个表的主键称此表的外键。

**3）SQL 约束有哪几种？**

*  NOT NULL: 用于控制字段的内容一定不能为空（NULL）。
 *  UNIQUE: 控件字段内容不能重复，一个表允许有多个 Unique 约束。
 *  PRIMARY KEY: 也是用于控件字段内容不能重复，但它在一个表只允许出现一个。
 *  FOREIGN KEY: 用于预防破坏表之间连接的动作，也能防止非法数据插入外键列，因为它必须是它指向的那个表中的值之一。
 *  CHECK: 用于控制字段的值范围。

**4）六种关联查询**

*  交叉连接（CROSS JOIN）
 *  **内连接（INNER JOIN）**
 *  **外连接（LEFT JOIN/RIGHT JOIN）**
 *  联合查询（UNION与UNION ALL）
 *  全连接（FULL JOIN）
 *  交叉连接（CROSS JOIN）

**5）什么是子查询**

*  条件：一条SQL语句的查询结果做为另一条查询语句的条件或查询结果
 *  嵌套：多条SQL语句嵌套使用，内部的SQL查询语句称为子查询。

**6）mysql中 in 和 exists 区别**

mysql中的in语句是把外表和内表作hash 连接，而exists语句是对外表作loop循环，每次loop循环再对内表进行查询。一直大家都认为exists比in语句的效率要高，这种说法其实是不准确的。这个是要区分环境的。

*  如果查询的两个表大小相当，那么用in和exists差别不大。
 *  如果两个表中一个较小，一个是大表，则子查询表大的用exists，子查询表小的用in。
 *  not in 和not exists：如果查询语句使用了not in，那么内外表都进行全表扫描，没有用到索引；而not extsts的子查询依然能用到表上的索引。所以无论那个表大，用not exists都比not in要快。

**7）varchar与char的区别**

**char的特点**

*  char表示定长字符串，长度是固定的；
 *  如果插入数据的长度小于char的固定长度时，则用空格填充；
 *  因为长度固定，所以存取速度要比varchar快很多，甚至能快50%，但正因为其长度固定，所以会占据多余的空间，是空间换时间的做法；
 *  对于char来说，最多能存放的字符个数为255，和编码无关

**varchar的特点**

*  varchar表示可变长字符串，长度是可变的；
 *  插入的数据是多长，就按照多长来存储；
 *  varchar在存取方面与char相反，它存取慢，因为长度不固定，但正因如此，不占据多余的空间，是时间换空间的做法；
 *  对于varchar来说，最多能存放的字符个数为65532

总之，结合性能角度（char更快）和节省磁盘空间角度（varchar更小），具体情况还需具体来设计数据库才是妥当的做法。

**8）varchar(50)中50的涵义**

最多存放50个字符，varchar(50)和(200)存储hello所占空间一样，但后者在排序时会消耗更多内存，因为order by col采用fixed\_length计算col长度(memory引擎也一样)。在早期 MySQL 版本中， 50 代表字节数，现在代表字符数。

**9）int(20)中20的涵义**

是指显示字符的长度。20表示最大显示宽度为20，但仍占4字节存储，存储范围不变；不影响内部存储，只是影响带 zerofill 定义的 int 时，前面补多少个 0，易于报表展示。int(1)和int(20)存储和计算均一样。

**10）mysql 中int(10)和char(10)以及varchar(10)的区别**

*  int(10)的10表示显示的数据的长度，不是存储数据的大小；chart(10)和varchar(10)的10表示存储数据的大小，即表示存储多少个字符。
    
     *  int(10) 10位的数据长度 9999999999，占32个字节，int型4位
     *  char(10) 10位固定字符串，不足补空格 最多10个字符
     *  varchar(10) 10位可变字符串，不足补空格 最多10个字符
 *  char(10)表示存储定长的10个字符，不足10个就用空格补齐，占用更多的存储空间
 *  varchar(10)表示存储10个变长的字符，存储多少个就是多少个，空格也按一个字符存储，这一点是和char(10)的空格不同的，char(10)的空格表示占位不算一个字符

**11）FLOAT和DOUBLE的区别是什么？**

*  FLOAT类型数据可以存储至多8位十进制数，并在内存中占4字节。
 *  DOUBLE类型数据可以存储至多18位十进制数，并在内存中占8字节。

**12）drop、delete与truncate的区别**

三者都表示删除，但是三者有一些差别：

<table> 
 <thead> 
  <tr> 
   <th>&nbsp;</th> 
   <th>Delete</th> 
   <th>Truncate</th> 
   <th>Drop</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>类型</td> 
   <td>属于DML</td> 
   <td>属于DDL</td> 
   <td>属于DDL</td> 
  </tr> 
  <tr> 
   <td>回滚</td> 
   <td>可回滚</td> 
   <td>不可回滚</td> 
   <td>不可回滚</td> 
  </tr> 
  <tr> 
   <td>删除内容</td> 
   <td>表结构还在，删除表的全部或者一部分数据行</td> 
   <td>表结构还在，删除表中的所有数据</td> 
   <td>从数据库中删除表，所有的数据行，索引和权限也会被删除</td> 
  </tr> 
  <tr> 
   <td>删除速度</td> 
   <td>删除速度慢，需要逐行删除</td> 
   <td>删除速度快</td> 
   <td>删除速度最快</td> 
  </tr> 
 </tbody> 
</table>

因此，在不再需要一张表的时候，用drop；在想删除部分数据行时候，用delete；在保留表而删除所有数据的时候用truncate。

**13）UNION与UNION ALL的区别？**

*  如果使用UNION ALL，不会合并重复的记录行
 *  效率 UNION 高于 UNION ALL

## 二、事务 ##

事务是一个不可分割的数据库操作序列，也是数据库并发控制的基本单位，其执行的结果必须使数据库从一种一致性状态变到另一种一致性状态。事务是逻辑上的一组操作，要么都执行，要么都不执行。

### 1、事务四大特性（ACID） ###

*  原子性：不可分割的操作单元，事务中所有操作，要么全部成功；要么撤回到执行事务之前的状态
 *  一致性：如果在执行事务之前数据库是一致的，那么在执行事务之后数据库也还是一致的；
 *  隔离性：事务操作之间彼此独立和透明互不影响。事务独立运行。这通常使用锁来实现。一个事务处理后的结果，影响了其他事务，那么其他事务会撤回。事务的100%隔离，需要牺牲速度。
 *  持久性：事务一旦提交，其结果就是永久的。即便发生系统故障，也能恢复。

### 2、脏读、不可重复读、幻读 ###

*  脏读: 是指事务T1将某一值修改，然后事务T2读取该值，此后T1因为某种原因撤销对该值的修改，这就导致了T2所读取到的数据是无效的。
 *  不可重复读 ：是指在数据库访问时，一个事务范围内的两次相同查询却返回了不同数据。
 *  幻读: 是指当事务不是独立执行时发生的一种现象，比如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么就会发生，操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样。

**    不可重复读&幻读区别：不可重复读重点在于update和delete，而幻读的重点在于insert。**

### 3、事务隔离级别 ###

*  未提交读(Read Uncommitted)：允许脏读，其他事务只要修改了数据，即使未提交，本事务也能看到修改后的数据值。也就是可能读取到其他会话中未提交事务修改的数据
 *  提交读(Read Committed)：只能读取到已经提交的数据。**Oracle等多数数据库默认都是该级别 (不重复读)**。
 *  可重复读(Repeated Read)：可重复读。无论其他事务是否修改并提交了数据，在这个事务中看到的数据值始终不受其他事务影响。**MySQL数据库(InnoDB引擎)默认使用可重复读**（ Repeatable read)。
 *  串行读(Serializable)：完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞。

## 三、索引 ##

### 1、啥是索引 ###

数据库索引是建立在表的一列或多个列上的辅助对象，用于加快数据的检索，类似于书籍的索引。当数据库表中的数据越来越多的时候，查询效率变慢，这时候我们就需要数据库索引了。索引的实现通常使用 B+TREE，B+TREE 索引加速了数据访问，因为存储引擎不会再去扫描整张表得到需要的数据；相反，它从根节点开始，根节点保存了子节点的指针，存储引擎会根据指针快速寻找数据。

**优点：**

1.  加快数据的查询速度；
2.  唯一索引可以确保数据的唯一性；
3.  可以加速表和表之间的连接，实现表和表之间的参照完整性；
4.  使用分组和排序子句进行数据检索时，可以显著减少查询中分组和排序的时间。

**缺点：**

1.  占用数据表以外的物理存储空间；
2.  需要对索引进行维护；
3.  表进行更新操作时，索引需要被重建，降低了数据的维护速度。

### 2、索引的分类 ###

MySQL数据库的五类索引:

1.  普通索引，数据可以重复，没有任何限制。
2.  唯一索引，要求索引列的值必须唯一，但允许有空值；如果是组合索引，那么列值的组合必须唯一。
3.  主键索引，是一种特殊的唯一索引，一个表只能有一个主键，不允许有空值，一般是在创建表的同时创建主键索引。
4.  组合索引 ，在多个字段上创建的索引，只有在查询条件中使用了创建索引时的第一个字段，索引才会被使用。
5.  全文索引，是对于大表的文本域：char，varchar，text列才能创建全文索引，主要用于查找文本中的关键字，并不是直接与索引中的值进行比较。fulltext更像是一个搜索引擎，配合match against操作使用，而不是一般的where语句加like。

**注:全文索引目前只有MyISAM存储引擎支持全文索引，InnoDB引擎5.6以下版本还不支持全文索引**

### 3、索引的实现方式 ###

索引的数据结构和具体存储引擎的实现有关，在MySQL中使用较多的索引有**Hash索引**，**B+树索引**等，而我们经常使用的InnoDB存储引擎的默认索引实现为：B+树索引。对于哈希索引来说，底层的数据结构就是哈希表，因此在绝大多数需求为单条记录查询的时候，可以选择哈希索引，查询性能最快；其余大部分场景，建议选择BTree索引。

**1、 B+树**

B+树和红黑树差不多，都是是为了尽量保持树的平衡。但红黑树是二叉树，B+树是多叉树，节点下面可以有多个子节点，数据库会默认设置子节点数的一个最大值，这个值不会太小，所以B+树一般来说比较矮胖，而红黑树就比较瘦高。

如果经常需要同时对两个字段进行and查询,那么使用两个单独索引不如建立一个复合索引，因为两个单独索引通常数据库只能使用其中一个，而使用复合索引因为索引本身就对应到两个字段上的，效率会有很大提高。BTree是最常用的mysql数据库索引算法，也是mysql默认的算法。因为它不仅可以被用在=,>,>=,<,<=和between这些比较操作符上，而且还可以用于like操作符，只要它的查询条件是一个不以通配符开头的常量。

查询方式：

*  主键索引区:PI(关联保存的时数据的地址)按主键查询,
 *  普通索引区:si(关联的id的地址,然后再到达上面的地址)。所以按主键查询,速度最快

B+tree性质：

*  n棵子tree的节点包含n个关键字，不用来保存数据而是保存数据的索引。
 *  所有的叶子结点中包含了全部关键字的信息，及指向含这些关键字记录的指针，且叶子结点本身依关键字的大小自小而大顺序链接。
 *  所有的非终端结点可以看成是索引部分，结点中仅含其子树中的最大（或最小）关键字。
 *  B+ 树中，数据对象的插入和删除仅在叶节点上进行。
 *  B+树有2个头指针，一个是树的根节点，一个是最小关键码的叶节点。

**2、散列索引**

散列索引，又叫哈希索引，是通过散列函数来定位的一种索引。不过很少有单独使用散列索引的，反而是散列文件组织用的比较多。

散列文件组织就是根据一个键通过散列计算把对应的记录都放到同一个槽中，这样的话相同的键值对应的记录就一定是放在同一个文件里了，也就减少了文件读取的次数，提高了效率。

散列索引呢就是根据对应键的散列码来找到最终的索引项的技术，其实和B树就差不多了，也就是一种索引之上的二级辅助索引，我理解散列索引都是二级或更高级的稀疏索引，否则桶就太多了，效率也不会很高。

Hash索引只能用于对等比较，例如=,<=>（相当于=）操作符。由于是一次定位数据，不像BTree索引需要从根节点到枝节点，最后才能访问到页节点这样多次IO访问，所以检索效率远高于BTree索引。

**3、位图索引**

位图索引是一种针对多个字段的简单查询设计一种特殊的索引，适用范围比较小，只适用于字段值固定并且值的种类很少的情况，比如性别，只能有男和女，或者级别，状态等，并且只有在同时对多个这样的字段查询时才能体现出位图的优势。

**create bitmap index idx\_name on table(col\_name)**

位图的基本思想就是对每一个条件都用0或者1来表示，如有5条记录，性别分别是男，女，男，男，女，那么如果使用位图索引就会建立两个位图，对应男的10110和对应女的01001,这样做有什么好处呢，就是如果同时对多个这种类型的字段进行and或or查询时，可以使用按位与和按位或来直接得到结果了。

**4、mysql存储引擎使用的索引结构**

**MyISAM引擎使用B+Tree作为索引结构**，叶节点的data域存放的是数据记录的地址，即：MyISAM索引文件和数据文件是分离的，MyISAM的索引文件仅仅保存数据记录的地址。MyISAM中索引检索的算法为首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，则取出其data域的值，然后以data域的值为地址，读取相应数据记录。MyISAM的索引方式也叫做“非聚集”的。

**InnoDB引擎也使用B+Tree作为索引结构**，但是InnoDB的数据文件本身就是索引文件，叶节点data域保存了完整的数据记录。这个索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引。这种索引叫做“聚焦索引”。InnoDB的辅助索引的data域存储相应记录主键的值而不是地址。换句话说，InnoDB的所有辅助索引都引用主键作为data域。聚集索引这种实现方式使得按主键的搜索十分高效，但是辅助索引搜索需要检索两遍索引：首先检索辅助索引获得主键，然后用主键到主索引中检索获得记录。InnoDB的索引实现后，不建议使用过长的字段作为主键，因为所有辅助索引都引用主索引，过长的主索引会令辅助索引变得过大。在Innodb中也不建议使用非单调的字段作为主键，因为InnoDB数据文件本身是一颗B+Tree，非单调的主键会造成在插入新记录时数据文件为了维持B+Tree的特性而频繁的分裂调整，十分低效，建议使用自增字段作为主键。

### 4、索引的基本原理 ###

索引用来快速地寻找那些具有特定值的记录。如果没有索引，一般来说执行查询时遍历整张表。

索引的原理很简单，就是把无序的数据变成有序的查询：

1.  把创建了索引的列的内容进行排序
2.  对排序结果生成倒排表
3.  在倒排表内容上拼上数据地址链
4.  在查询的时候，先拿到倒排表内容，再取出数据地址链，从而拿到具体数据

### 5、索引的创建原则 ###

凡事都有两面，有利必有弊。建立索引也是同样的道理，我们在增加了检索速度的同时，也会损耗相当的更新性能。所以建立索引前，要慎重的讨论清楚，确实需要的时候再加。

**应该创建索引的情况：**

1.  经常需要搜索的列，加快查询速度；
2.  主键列上，强调唯一性；
3.  经常用在连接的列，这些列主要是一些外键，可以加快连接的速度；
4.  经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的；
5.  经常需要排序的列上创建索引，因为索引已经排序，这样查询可以利用索引的排序，加快排序查询时间；
6.  经常使用在WHERE子句中的列上面创建索引，加快条件的判断速度。

**不应该创建索引的情况：**

1.  在查询中很少使用或者参考的列不应该创建索引。因为很少使用到，并不能提高查询速度。相反，由于增加了索引，反而降低了系统的维护速度和增大了空间需求。
2.  只有很少数据值的列也不应该增加索引。这是因为，由于这些列的取值很少，例如人事表的性别列，在查询的结果中，结果集的数据行占了表中数据行的很大比例，即需要在表中搜索的数据行的比例很大。增加索引，并不能明显加快检索速度。
3.  定义为text, image和bit数据类型的列不应该增加索引。这是因为，这些列的数据量要么相当大，要么取值很少。
4.  当修改性能远远大于检索性能时，不应该创建索引。这是因为，修改性能和检索性能是互相矛盾的。当增加索引时，会提高检索性能，但是会降低修改性能。当减少 索引时，会提高修改性能，降低检索性能。因此，当修改性能远远大于检索性能时，不应该创建索引。

**创建索引时需要注意什么？**

*  非空字段：应该指定列为NOT NULL，除非你想存储NULL。在mysql中，含有空值的列很难进行查询优化，因为它们使得索引、索引的统计信息以及比较运算更加复杂。你应该用0、一个特殊的值或者一个空串代替空值；
 *  取值离散大的字段：（变量各个取值之间的差异程度）的列放到联合索引的前面，可以通过count()函数查看字段的差异值，返回值越大说明字段的唯一值越多字段的离散程度高；
 *  索引字段越小越好：数据库的数据存储以页为单位一页存储的数据越多一次IO操作获取的数据越大效率越高。

### 6、百万级别或以上的数据如何删除？ ###

关于索引：由于索引需要额外的维护成本，因为索引文件是单独存在的文件,所以当我们对数据的增加,修改,删除,都会产生额外的对索引文件的操作,这些操作需要消耗额外的IO,会降低增/改/删的执行效率。所以，在我们删除数据库百万级别数据的时候，查询MySQL官方手册得知删除数据的速度和创建的索引数量是成正比的。

*  所以我们想要删除百万数据的时候可以先删除索引（此时大概耗时三分多钟）
 *  然后删除其中无用数据（此过程需要不到两分钟）
 *  删除完成后重新创建索引(此时数据较少了)创建索引也非常快，约十分钟左右。
 *  与之前的直接删除绝对是要快速很多，更别说万一删除中断,一切删除会回滚。那更是坑了。

### **7、B树和B+树的区别** ###

*  在B树中，你可以将键和值存放在内部节点和叶子节点；但在B+树中，内部节点都是键，没有值，叶子节点同时存放键和值。
 *  B+树的叶子节点有一条链相连，而B树的叶子节点各自独立。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70][]

**使用B+树的好处：**由于B+树的内部节点只存放键，不存放值，因此，一次读取，可以在内存页中获取更多的键，有利于更快地缩小查找范围。 B+树的叶节点由一条链相连，因此，当需要进行一次全数据遍历的时候，B+树只需要使用O(logN)时间找到最小的一个节点，然后通过链进行O(N)的顺序遍历即可。而B树则需要对树的每一层进行遍历，这会需要更多的内存置换次数，因此也就需要花费更多的时间。

### 8、Hash索引和B+树所有有什么区别或者说优劣呢? ###

首先要知道Hash索引和B+树索引的底层实现原理：

hash索引底层就是hash表，进行查找时，调用一次hash函数就可以获取到相应的键值，之后进行回表查询获得实际数据。B+树底层实现是多路平衡查找树。对于每一次的查询都是从根节点出发，查找到叶子节点方可以获得所查键值，然后根据查询判断是否需要回表查询数据。

那么可以看出他们有以下的不同：

*  hash索引进行等值查询更快(一般情况下)，但是却无法进行范围查询。

因为在hash索引中经过hash函数建立索引之后，索引的顺序与原顺序无法保持一致，不能支持范围查询。而B+树的的所有节点皆遵循(左节点小于父节点，右节点大于父节点，多叉树也类似)，天然支持范围。

*  hash索引不支持使用索引进行排序，原理同上。
 *  hash索引不支持模糊查询以及多列索引的最左前缀匹配。原理也是因为hash函数的不可预测。AAAA和AAAAB的索引没有相关性。
 *  hash索引任何时候都避免不了回表查询数据，而B+树在符合某些条件(聚簇索引，覆盖索引等)的时候可以只通过索引完成查询。
 *  hash索引虽然在等值查询上较快，但是不稳定。性能不可预测，当某个键值存在大量重复的时候，发生hash碰撞，此时效率可能极差。而B+树的查询效率比较稳定，对于所有的查询都是从根节点到叶子节点，且树的高度较低。

因此，在大多数情况下，直接选择B+树索引可以获得稳定且较好的查询速度。而不需要使用hash索引。

### 9、数据库为什么使用B+树而不是B树？ ###

*  B树只适合随机检索，而B+树同时支持随机检索和顺序检索；
 *  B+树空间利用率更高，可减少I/O次数，磁盘读写代价更低。一般来说，索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上。这样的话，索引查找过程中就要产生磁盘I/O消耗。B+树的内部结点并没有指向关键字具体信息的指针，只是作为索引使用，其内部结点比B树小，盘块能容纳的结点中关键字数量更多，一次性读入内存中可以查找的关键字也就越多，相对的，IO读写次数也就降低了。而IO读写次数是影响索引检索效率的最大因素；
 *  B+树的查询效率更加稳定。B树搜索有可能会在非叶子结点结束，越靠近根节点的记录查找时间越短，只要找到关键字即可确定记录的存在，其性能等价于在关键字全集内做一次二分查找。而在B+树中，顺序检索比较明显，随机检索时，任何关键字的查找都必须走一条从根节点到叶节点的路，所有关键字的查找路径长度相同，导致每一个关键字的查询效率相当。
 *  B树在提高了磁盘IO性能的同时并没有解决元素遍历的效率低下的问题。B+树的叶子节点使用指针顺序连接在一起，只要遍历叶子节点就可以实现整棵树的遍历。而且在数据库中基于范围的查询是非常频繁的，而B树不支持这样的操作。
 *  增删文件（节点）时，效率更高。因为B+树的叶子节点包含所有关键字，并以有序的链表结构存储，这样可很好提高增删效率。
 *  B+树在满足聚簇索引和覆盖索引的时候不需要回表查询数据。

### 10、什么是聚簇索引？何时使用聚簇索引与非聚簇索引？ ###

*  聚簇索引：将数据存储与索引放到了一块，找到索引也就找到了数据
 *  非聚簇索引：将数据存储于索引分开结构，索引结构的叶子节点指向了数据的对应行，myisam通过key\_buffer把索引先缓存到内存中，当需要访问数据时（通过索引访问数据），在内存中直接搜索索引，然后通过索引找到磁盘相应数据，这也就是为什么索引不在key buffer命中时，速度慢的原因

### 11、非聚簇索引一定会回表查询吗？ ###

不一定，这涉及到查询语句所要求的字段是否全部命中了索引，如果全部命中了索引，那么就不必再进行回表查询。

举个简单的例子，假设我们在员工表的年龄上建立了索引，那么当进行`select age from employee where age < 20`的查询时，在索引的叶子节点上，已经包含了age信息，不会再次进行回表查询。

### 12、联合索引是什么？为什么需要注意联合索引中的顺序？ ###

MySQL可以使用多个字段同时建立一个索引，叫做联合索引。在联合索引中，如果想要命中索引，需要按照建立索引时的字段顺序挨个使用，否则无法命中索引。

具体原因为:

MySQL使用索引时需要索引有序，假设现在建立了"name，age，school"的联合索引，那么索引的排序为: 先按照name排序，如果name相同，则按照age排序，如果age的值也相等，则按照school进行排序。

当进行查询时，此时索引仅仅按照name严格有序，因此必须首先使用name字段进行等值查询，之后对于匹配到的列而言，其按照age字段严格有序，此时可以使用age字段用做索引查找，以此类推。因此在建立联合索引的时候应该注意索引列的顺序，一般情况下，将查询需求频繁或者字段选择性高的列放在前面。此外可以根据特例的查询或者表结构进行单独的调整。

## 四、MySQL 存储引擎 ##

MySQL支持多种存储引擎,比如**InnoDB,MyISAM,Memory,Archive**等等.在大多数的情况下,直接选择使用InnoDB引擎都是最合适的，InnoDB也是MySQL的默认存储引擎。

### 1、MyISAM ###

MyISAM的特点是查询速度快、存储空间小，原因是在磁盘上分成三个文件存储：.frm(存储表定义)，.MYD(MYData，存储数据)，.MYI(MYIndex，存储索引)，SELECT COUNT(\*) FROM TABLE时，避免了全表扫描。

但是MyISAM不支持事务，也不支持外键，写入时是表锁，所以适合查询多、写入少的业务场景。

### 2、InnoDB ###

InnoDB，最大的特点就是支持事务和行锁，是现在Mysql的默认存储引擎。对事务和写并发的支持使InnDB成为互联网公司最常使用的存储引擎。

*  事务：支持ACID的事务，支持事务的四种隔离级别。
 *  行锁：支持行级锁及外键约束，所以在可以支持写并发。
 *  全表扫描：SELECT COUNT(\*) FROM TABLE时会进行全表扫描，效率低于MyISAM。

### 3、MEMORY ###

MEMORY是一种特殊的存储引擎，特点是使用存储在内存中的内容来创建表，并且数据全部放在内存中。每个基于MEMORY存储引擎的表实际对应一个磁盘文件。该文件的文件名与表名相同，类型为frm类型。该文件中只存储表的结构，而其数据文件，都是存储在内存中，这样有利于数据的快速处理，提高整个表的效率。需要注意的是，服务器需要有足够的内存来维持MEMORY存储引擎的表的使用。如果不需要了，可以释放内存，甚至删除不需要的表。

MEMORY默认使用哈希索引，速度比使用B树索引快。当然如果你想用B型树索引，可以在创建索引时指定。注意，MEMORY用到的很少，因为它是把数据存到内存中，如果内存出现异常就会影响数据。如果重启或者关机，所有数据都会消失。因此，基于MEMORY的表的生命周期很短，一般是一次性的。

### 4、三种存储引擎的特点 ###

*  1）InnoDB：支持事务处理，支持外键，支持崩溃修复能力和并发控制。
 *  2）MyISAM：占用空间小，查询速度快。缺点是不支持事务的完整性和并发性。
 *  3）MEMORY：所有的数据都在内存中，处理速度快，但是安全性不高。对表的大小有要求，依赖内存，不能建立太大的表。

### **5、MyISAM和InnoDB区别** ###

1.  InnoDB支持事务，MyISAM不支持。
2.  MyISAM适合查询以及插入为主的应用，InnoDB适合频繁修改以及涉及到安全性较高的应用。
3.  InnoDB支持外键，MyISAM不支持。
4.  从MySQL5.5.5以后，InnoDB是默认引擎。
5.  MyISAM支持全文类型索引，而InnoDB不支持全文索引。
6.  InnoDB中不保存表的总行数，select count(\*) from table时，InnoDB需要扫描整个表计算有多少行，但MyISAM只需简单读出保存好的总行数即可。注：当count(\*)语句包含where条件时MyISAM也需扫描整个表。
7.  对于自增长的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中可以和其他字段一起建立联合索引。
8.  清空整个表时，InnoDB是一行一行的删除，效率非常慢。MyISAM则会重建表。MyisAM使用delete语句删除后并不会立刻清理磁盘空间，需要定时清理，命令：OPTIMIZE table dept;
9.  InnoDB支持行锁（某些情况下还是锁整表，如 update table set a=1 where user like ‘%lee%’）
10. Myisam创建表生成三个文件：.frm 数据表结构 、 .myd 数据文件 、 .myi 索引文件，Innodb只生成一个 .frm文件，数据存放在ibdata1.log

现在一般都选用InnoDB，主要是MyISAM的全表锁，读写串行问题，并发效率锁表，效率低，MyISAM对于读写密集型应用一般是不会去选用的。

应用场景：

*  MyISAM不支持事务处理等高级功能，但它提供高速存储和检索，以及全文搜索能力。如果应用中需要执行大量的SELECT查询，那么MyISAM是更好的选择。
 *  InnoDB用于需要事务处理的应用程序，包括ACID事务支持。如果应用中需要执行大量的INSERT或UPDATE操作，则应该使用InnoDB，这样可以提高多用户并发操作的性能。

## 五、锁 ##

当数据库有并发事务的时候,可能会产生数据的不一致,这时候需要一些机制来保证访问的次序,锁机制就是这样的一个机制。

### 1、锁分类 ###

从锁的类别上来分,有共享锁和排他锁。

*  共享锁: 又叫做读锁. 当用户要进行数据的读取时,对数据加上共享锁.共享锁可以同时加上多个。
 *  排他锁: 又叫做写锁. 当用户要进行数据的写入时,对数据加上排他锁.排他锁只可以加一个,他和其他的排他锁,共享锁都相斥。

从锁的粒度来分，行级锁、页级锁、表级锁。他们的加锁开销从大大小,并发能力也是从大到小。

*  行级锁
 *  页级锁
 *  表级锁

**MyISAM采用表级锁，InnoDB支持行级锁和表级锁,默认为行级锁。**表级锁和行级锁对比：

*  表级锁： Mysql中锁定 粒度最大 的一种锁，对当前操作的整张表加锁，实现简单，资源消耗也比较少，加锁快，不会出现死锁。其锁定粒度最大，触发锁冲突的概率最高，并发度最低，MyISAM和 InnoDB引擎都支持表级锁。
 *  行级锁： Mysql中锁定 粒度最小 的一种锁，只针对当前操作的行进行加锁。 行级锁能大大减少数据库操作的冲突。其加锁粒度最小，并发度高，但加锁的开销也最大，加锁慢，会出现死锁。

InnoDB存储引擎的锁的算法有三种：

*  Record lock：单个行记录上的锁。
 *  Gap lock：间隙锁，锁定一个范围，不包括记录本身。
 *  Next-key lock：record+gap 锁定一个范围，包含记录本身。

### 2、隔离级别与锁的关系 ###

*  在Read Uncommitted级别下，读取数据不需要加共享锁，这样就不会跟被修改的数据上的排他锁冲突；
 *  在Read Committed级别下，读操作需要加共享锁，但是在语句执行完以后释放共享锁；
 *  在Repeatable Read级别下，读操作需要加共享锁，但是在事务提交之前并不释放共享锁，也就是必须等待事务执行完毕以后才释放共享锁；
 *  SERIALIZABLE 是限制性最强的隔离级别，因为该级别**锁定整个范围的键**，并一直持有锁，直到事务完成。

### 3、死锁 ###

死锁是指两个或多个事务在同一资源上相互占用，并请求锁定对方的资源，从而导致恶性循环的现象。

常见的解决死锁的方法：

*  如果不同程序会并发存取多个表，尽量约定以相同的顺序访问表，可以大大降低死锁机会。
 *  在同一个事务中，尽可能做到一次锁定所需要的所有资源，减少死锁产生概率；
 *  对于非常容易产生死锁的业务部分，可以尝试使用升级锁定颗粒度，通过表级锁定来减少死锁产生的概率；如果业务处理不好可以用分布式事务锁或者使用乐观锁。

### 4、乐观锁和悲观锁 ###

数据库管理系统（DBMS）中的并发控制的任务是确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性。乐观并发控制（乐观锁）和悲观并发控制（悲观锁）是并发控制主要采用的技术手段。

**1）悲观锁**：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。在查询完数据的时候就把事务锁起来，直到提交事务。实现方式：使用数据库中的锁机制

**2）乐观锁**：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。在修改数据的时候把事务锁起来，通过version的方式来进行锁定。实现方式：乐一般会使用版本号机制或CAS算法实现。

**两种锁的使用场景**

从上面对两种锁的介绍，我们知道两种锁各有优缺点，不可认为一种好于另一种，像**乐观锁适用于写比较少的情况下（多读场景）**，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。

但如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了性能，所以**一般多写的场景下用悲观锁就比较合适。**

### 5、MySQL中InnoDB引擎的行锁是怎么实现的？ ###

答：**InnoDB是基于索引来完成行锁**。

例: select \* from tab\_with\_index where id = 1 for update;

for update 可以根据条件来完成行锁锁定，并且 id 是有索引键的列，如果 id 不是索引键那么InnoDB将完成表锁，并发将无从谈起。

### 6、MVCC 锁并发 ###

**1）什么是MVCC？**

MVCC (Multi-Version Concurrency Control) (注：与MVCC相对的，是基于锁的并发控制，Lock-Based Concurrency Control)是一种基于多版本的并发控制协议，只有在InnoDB引擎下存在。MVCC是为了实现事务的隔离性，通过版本号，避免同一数据在不同事务间的竞争，你可以把它当成基于多版本号的一种乐观锁。当然，这种乐观锁只在事务级别未提交锁和已提交锁时才会生效。MVCC最大的好处，相信也是耳熟能详：读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不冲突是非常重要的，极大的增加了系统的并发性能。具体见下面介绍。

**2）MVCC的实现机制**

InnoDB在每行数据都增加两个隐藏字段，一个记录创建的版本号，一个记录删除的版本号。

在多版本并发控制中，为了保证数据操作在多线程过程中，保证事务隔离的机制，降低锁竞争的压力，保证较高的并发量。在每开启一个事务时，会生成一个事务的版本号，被操作的数据会生成一条新的数据行（临时），但是在提交前对其他事务是不可见的，对于数据的更新（包括增删改）操作成功，会将这个版本号更新到数据的行中，事务提交成功，将新的版本号更新到此数据行中，这样保证了每个事务操作的数据，都是互不影响的，也不存在锁的问题。

## 六、SQL的生命周期 ##

1.  应用服务器与数据库服务器建立一个连接
2.  数据库进程拿到请求sql
3.  解析并生成执行计划，执行
4.  读取数据到内存并进行逻辑处理
5.  通过步骤一的连接，发送结果到客户端
6.  关掉连接，释放资源

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 1][]

## 七、SQL优化 ##

### 1、关心过业务系统里面的sql耗时吗？统计过慢查询吗？对慢查询都怎么优化过？ ###

在业务系统中，除了使用主键进行的查询，其他的我都会在测试库上测试其耗时，慢查询的统计主要由运维在做，会定期将业务中的慢查询反馈给我们。

慢查询的优化首先要搞明白慢的原因是什么？ 是查询条件没有命中索引？是load了不需要的数据列？还是数据量太大？

所以优化也是针对这三个方向来的，

*  首先分析语句，看看是否load了额外的数据，可能是查询了多余的行并且抛弃掉了，可能是加载了许多结果中并不需要的列，对语句进行分析以及重写。
 *  分析语句的执行计划，然后获得其使用索引的情况，之后修改语句或者修改索引，使得语句可以尽可能的命中索引。
 *  如果对语句的优化已经无法进行，可以考虑表中的数据量是否太大，如果是的话可以进行横向或者纵向的分表。

### 2、优化查询过程中的数据访问 ###

*  访问数据太多导致查询性能下降
 *  确定应用程序是否在检索大量超过需要的数据，可能是太多行或列
 *  确认MySQL服务器是否在分析大量不必要的数据行
 *  避免犯如下SQL语句错误
 *  查询不需要的数据。解决办法：使用limit解决
 *  多表关联返回全部列。解决办法：指定列名
 *  总是返回全部列。解决办法：避免使用SELECT \*
 *  重复查询相同的数据。解决办法：可以缓存数据，下次直接读取缓存
 *  是否在扫描额外的记录。解决办法：
 *  使用explain进行分析，如果发现查询需要扫描大量的数据，但只返回少数的行，可以通过如下技巧去优化：
 *  使用索引覆盖扫描，把所有的列都放到索引中，这样存储引擎不需要回表获取对应行就可以返回结果。
 *  改变数据库和表的结构，修改数据表范式
 *  重写SQL语句，让优化器可以以更优的方式执行查询。

### 3、优化长难的查询语句 ###

*  一个复杂查询还是多个简单查询
 *  MySQL内部每秒能扫描内存中上百万行数据，相比之下，响应数据给客户端就要慢得多
 *  使用尽可能小的查询是好的，但是有时将一个大的查询分解为多个小的查询是很有必要的。
 *  切分查询
 *  将一个大的查询分为多个小的相同的查询
 *  一次性删除1000万的数据要比一次删除1万，暂停一会的方案更加损耗服务器开销。
 *  分解关联查询，让缓存的效率更高。
 *  执行单个查询可以减少锁的竞争。
 *  在应用层做关联更容易对数据库进行拆分。
 *  查询效率会有大幅提升。
 *  较少冗余记录的查询。

### 4、优化特定类型的查询语句 ###

*  count(\*)会忽略所有的列，直接统计所有列数，不要使用count(列名)
 *  MyISAM中，没有任何where条件的count(\*)非常快。
 *  当有where条件时，MyISAM的count统计不一定比其它引擎快。
 *  可以使用explain查询近似值，用近似值替代count(\*)
 *  增加汇总表
 *  使用缓存

### 5、优化关联查询 ###

*  确定ON或者USING子句中是否有索引。
 *  确保GROUP BY和ORDER BY只有一个表中的列，这样MySQL才有可能使用索引。

### 6、优化子查询 ###

*  用关联查询替代
 *  优化GROUP BY和DISTINCT
 *  这两种查询据可以使用索引来优化，是最有效的优化方法
 *  关联查询中，使用标识列分组的效率更高
 *  如果不需要ORDER BY，进行GROUP BY时加ORDER BY NULL，MySQL不会再进行文件排序。
 *  WITH ROLLUP超级聚合，可以挪到应用程序处理

### 7、优化LIMIT分页 ###

*  LIMIT偏移量大的时候，查询效率较低
 *  可以记录上次查询的最大ID，下次查询时直接根据该ID来查询

### 8、优化UNION查询 ###

*  UNION ALL的效率高于UNION

### 9、优化WHERE子句 ###

*  对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。
 *  应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描。
 *  应尽量避免在 where 子句中使用!=或<>操作符，否则引擎将放弃使用索引而进行全表扫描。
 *  应尽量避免在 where 子句中使用or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描。
 *  in 和 not in 也要慎用，否则会导致全表扫描。
 *  下面的查询也将导致全表扫描：select id from t where name like ‘%李%’若要提高效率，可以考虑全文检索。
 *  如果在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然 而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。
 *  应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。
 *  应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。
 *  不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。

## 八、数据库优化 ##

### 1、数据库结构优化 ###

一个好的数据库设计方案对于数据库的性能往往会起到事半功倍的效果。需要考虑数据冗余、查询和更新的速度、字段的数据类型是否合理等多方面的内容。

**1）将字段很多的表分解成多个表**

对于字段较多的表，如果有些字段的使用频率很低，可以将这些字段分离出来形成新表。因为当一个表的数据量很大时，会由于使用频率低的字段的存在而变慢。

**2）增加中间表**

对于需要经常联合查询的表，可以建立中间表以提高查询效率。通过建立中间表，将需要通过联合查询的数据插入到中间表中，然后将原来的联合查询改为对中间表的查询。

**3）增加冗余字段**

设计数据表时应尽量遵循范式理论的规约，尽可能的减少冗余字段，让数据库设计看起来精致、优雅。但是，合理的加入冗余字段可以提高查询速度。表的规范化程度越高，表和表之间的关系越多，需要连接查询的情况也就越多，性能也就越差。

### 2、大表数据查询，怎么优化 ###

*  优化shema、sql语句+索引；
 *  第二加缓存，memcached, redis；
 *  主从复制，读写分离；
 *  垂直拆分，根据你模块的耦合度，将一个大的系统分为多个小的系统，也就是分布式系统；
 *  水平切分，针对数据量大的表，这一步最麻烦，最能考验技术水平，要选择一个合理的sharding key, 为了有好的查询效率，表结构也要改动，做一定的冗余，应用也要改，sql中尽量带sharding key，将数据定位到限定的表上去查，而不是扫描全部的表；

### 3、超大分页怎么处理？ ###

超大的分页一般从两个方向上来解决.

*  数据库层面,这也是我们主要集中关注的(虽然收效没那么大),类似于`select * from table where age > 20 limit 1000000,10`这种查询其实也是有可以优化的余地的. 这条语句需要load1000000数据然后基本上全部丢弃,只取10条当然比较慢. 当时我们可以修改为`select * from table where id in (select id from table where age > 20 limit 1000000,10)`.这样虽然也load了一百万的数据,但是由于索引覆盖,要查询的所有字段都在索引中,所以速度会很快. 同时如果ID连续的好,我们还可以`select * from table where id > 1000000 limit 10`,效率也是不错的,优化的可能性有许多种,但是核心思想都一样,就是减少load的数据.
 *  从需求的角度减少这种请求…主要是不做类似的需求(直接跳转到几百万页之后的具体某一页.只允许逐页查看或者按照给定的路线走,这样可预测,可缓存)以及防止ID泄漏且连续被人恶意攻击.

解决超大分页,其实主要是靠缓存,可预测性的提前查到内容,缓存至redis等k-V数据库中,直接返回即可。

### 4、慢查询日志 ###

> **1）开启慢查询日志**
> 
> 配置项：`slow_query_log`
> 
> 可以使用`show variables like ‘slov_query_log’`查看是否开启，如果状态值为`OFF`，可以使用`set GLOBAL slow_query_log = on`来开启，它会在`datadir`下产生一个`xxx-slow.log`的文件。
> 
> **2）设置临界时间**
> 
> 配置项：`long_query_time`
> 
> 查看：`show VARIABLES like 'long_query_time'`，单位秒
> 
> 设置：`set long_query_time=0.5`
> 
> 实操时应该从长时间设置到短的时间，即将最慢的SQL优化掉
> 
> 查看日志，一旦SQL超过了我们设置的临界时间就会被记录到`xxx-slow.log`中

### 5、MySQL数据库cpu飙升到500%的话他怎么处理？ ###

当 cpu 飙升到 500%时，先用操作系统命令 top 命令观察是不是 mysqld 占用导致的，如果不是，找出占用高的进程，并进行相关处理。如果是 mysqld 造成的， show processlist，看看里面跑的 session 情况，是不是有消耗资源的 sql 在运行。找出消耗高的 sql，看看执行计划是否准确， index 是否缺失，或者实在是数据量太大造成。

一般来说，肯定要 kill 掉这些线程(同时观察 cpu 使用率是否下降)，等进行相应的调整(比如说加索引、改 sql、改内存参数)之后，再重新跑这些 SQL。也有可能是每个 sql 消耗资源并不多，但是突然之间，有大量的 session 连进来导致 cpu 飙升，这种情况就需要跟应用一起来分析为何连接数会激增，再做出相应的调整，比如说限制连接数等

### 6、大表怎么优化？某个表有近千万数据，CRUD比较慢，如何优化？分库分表了是怎么做的？分表分库了有什么问题？有用到中间件么？他们的原理知道么？ ###

当MySQL单表记录数过大时，数据库的CRUD性能会明显下降，一些常见的优化措施如下：

1.  **限定数据的范围：** 务必禁止不带任何限制数据范围条件的查询语句。比如：我们当用户在查询订单历史的时候，我们可以控制在一个月的范围内。；
2.  **读/写分离：** 经典的数据库拆分方案，主库负责写，从库负责读；
3.  **缓存：** 使用MySQL的缓存，另外对重量级、更新少的数据可以考虑使用应用级别的缓存；

还有就是通过分库分表的方式进行优化，主要有垂直分表和水平分表。

## 九、分库分表（一） ##

### 1、垂直拆分 ###

**根据数据库里面数据表的相关性进行拆分。** 例如，用户表中既有用户的登录信息又有用户的基本信息，可以将用户表拆分成两个单独的表，甚至放到单独的库做分库。**简单来说垂直拆分是指数据表列的拆分，把一张列比较多的表拆分为多张表。** 如下图所示，这样来说大家应该就更容易理解了。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 2][]

*  **垂直拆分的优点：** 可以使得行数据变小，在查询时减少读取的Block数，减少I/O次数。此外，垂直分区可以简化表的结构，易于维护。
 *  **垂直拆分的缺点：** 主键会出现冗余，需要管理冗余列，并会引起Join操作，可以通过在应用层进行Join来解决。此外，垂直分区会让事务变得更加复杂；

垂直分表，把主键和一些列放在一个表，然后把主键和另外的列放在另一个表中，如下图，

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 3][]

适用场景：

*  如果一个表中某些列常用，另外一些列不常用
 *  可以使数据行变小，一个数据页能存储更多数据，查询时减少I/O次数

缺点：

*  有些分表的策略基于应用层的逻辑算法，一旦逻辑算法改变，整个分表逻辑都会改变，扩展性较差
 *  对于应用层来说，逻辑算法增加开发成本
 *  管理冗余列，查询所有数据需要join操作

### 2、水平拆分 ###

**保持数据表结构不变，通过某种策略存储数据分片。这样每一片数据分散到不同的表或者库中，达到了分布式的目的。 水平拆分可以支撑非常大的数据量。**

水平拆分是指数据表行的拆分，表的行数超过200万行时，就会变慢，这时可以把一张的表的数据拆成多张表来存放。举个例子：我们可以将用户信息表拆分成多个用户信息表，这样就可以避免单一表数据量过大对性能造成影响。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 4][]

水品拆分可以支持非常大的数据量。需要注意的一点是:分表仅仅是解决了单一表数据过大的问题，但由于表的数据还是在同一台机器上，其实对于提升MySQL并发能力没有什么意义，所以 **水平拆分最好分库** 。

水平拆分能够 **支持非常大的数据量存储，应用端改造也少**，但 **分片事务难以解决** ，跨界点Join性能较差，逻辑复杂。推荐 **尽量不要对数据进行分片，因为拆分会带来逻辑、部署、运维的各种复杂度** ，一般的数据表在优化得当的情况下支撑千万以下的数据量是没有太大问题的。如果实在要分片，尽量选择客户端分片架构，这样可以减少一次和中间件的网络I/O。

水平分表，表很大，分割后可以降低在查询时需要读的数据和索引的页数，同时也降低了索引的层数，提高查询次数。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 5][]

适用场景

*  表中的数据本身就有独立性，例如表中分表记录各个地区的数据或者不同时期的数据，特别是有些数据常用，有些不常用。
 *  需要把数据存放在多个介质上。

水平切分的缺点

*  给应用增加复杂度，通常查询时需要多个表名，查询所有数据都需UNION操作
 *  在许多数据库应用中，这种复杂度会超过它带来的优点，查询时会增加读一个索引层的磁盘次数

### **3、数据库分片的两种常见方案** ###

**1）客户端代理：** **分片逻辑在应用端，封装在jar包中，通过修改或者封装JDBC层来实现。** 当当网的 **Sharding-JDBC** 、阿里的TDDL是两种比较常用的实现。

**2）中间件代理：** **在应用和数据中间加了一个代理层。分片逻辑统一维护在中间件服务中。** 我们现在谈的 **Mycat** 、360的Atlas、网易的DDB等等都是这种架构的实现。

### **4、分库分表后面临的问题** ###

1）面临的问题

*  **事务支持：**分库分表后，就成了分布式事务了。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价； 如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。
 *  **跨库join：**只要是进行切分，跨节点Join的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据。 分库分表方案产品
 *  **跨节点的count,order by,group by以及聚合函数问题：**这些是一类问题，因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。解决方案：与解决跨节点join问题的类似，分别在各个节点上得到结果后在应用程序端进行合并。和join不同的是每个结点的查询可以并行执行，因此很多时候它的速度要比单一大表快很多。但如果结果集很大，对应用程序内存的消耗是一个问题。
 *  **数据迁移，容量规划，扩容等问题：**来自淘宝综合业务平台团队，它利用对2的倍数取余具有向前兼容的特性（如对4取余得1的数对2取余也是1）来分配数据，避免了行级别的数据迁移，但是依然需要进行表级别的迁移，同时对扩容规模和分表数量都有限制。总得来说，这些方案都不是十分的理想，多多少少都存在一些缺点，这也从一个侧面反映出了Sharding扩容的难度。
 *  **ID问题**：一旦数据库被切分到多个物理结点上，我们将不能再依赖数据库自身的主键生成机制。一方面，某个分区数据库自生成的ID无法保证在全局上是唯一的；另一方面，应用程序在插入数据之前需要先获得ID,以便进行SQL路由。
 *  **跨分片的排序分页：**需要在不同的分片节点中将数据进行排序并返回，并将不同分片返回的结果集进行汇总和再次排序，最后再返回给用户。

2） 常见的主键生成策略

**UUID** 使用UUID作主键是最简单的方案，但是缺点也是非常明显的。由于UUID非常的长，除占用大量存储空间外，最主要的问题是在索引上，在建立索引和基于索引进行查询时都存在性能问题。 **Twitter的分布式自增ID算法Snowflake** 在分布式系统中，需要生成全局UID的场合还是比较多的，twitter的snowflake解决了这种需求，实现也还是很简单的，除去配置信息，核心代码就是毫秒级时间41位 机器ID 10位 毫秒内序列12位。

## 九、分库分表（二） ##

### 1、数据切分 ###

数据切分（Sharding），简单的来说，就是通过某种特定的条件，将存放在同一个数据库中的数据拆分存放到多个数据库（主机）中，从而达到分散单台机器负载的情况，即分库分表。根据数据切分规则的不同，主要有两种模式，

*  **垂直切分（纵向切分）**，是对不同的表（或者Schema）进行切分，存储到不同的数据库（主机）之上。
 *  **水平切分（横向切分）**，是对同一个表中的数据进行切分，存储到不同的数据库（主机）之上。规则是根据表中数据的逻辑关系，按照某种条件拆分。

### 2、垂直切分 ###

垂直切分，强调的是业务的拆分。一个数据库由多个表构成，每个表对应不同的业务，那么我们可以指按照业务的不同将表进行分类，并将其分布到不同的数据库上，这样就将数据分摊到了不同的库上面，做到专库专用。

举个例子，原数据库中有商品表、交易表、订单表，我们可以按照业务的不同进行垂直切分，把商品表、交易表、订单表分别拆分到商品库、交易库、订单库中去。

垂直拆分的优点：

*  拆分规则明确，拆分后业务清晰；
 *  系统之间进行整合或扩展变的容易；
 *  数据维护变的容易；
 *  按照成本、应用的等级、应用的类型等将表放到不同的机器上，便于管理。

垂直拆分的缺点：

*  部分业务表无法关联（Join），只能通过接口方式解决，提高了系统的复杂度；
 *  受每种业务的不同限制，存在单库性能瓶颈，不易进行数据扩展和提升性能；
 *  分布式事务处理复杂。

### 3、水平切分（重点） ###

水平切分，强调的是技术层面的拆分。她是将其按照一定的逻辑规则将一个表中的数据分散到多个库中，在每个表中包含一部分数据，所有表加起来就是全量的数据。简单来说，我们可以将对数据的水平切分理解为按照数据行进行切分，就是将表中的某些行切分到一个数据库表中，而将其他行切分到其他数据库表中。

比如，原数据库有一张交易记录表，数据量非常大，其中表中有个地区字段，经过深入考证符合水平拆分的条件。我们就按照这个字段进行水平拆分，按不同的地区（北京、上海、江苏、浙江、广东等）拆分成10个库。

高峰时段同时有100万次请求，如果是单库，数据库就会承受100万次的请求压力，拆分成100个表分别放入10个库中，每个表进行1万次请求，则每个数据库会承受10万次的请求压力，这样压力就减少了很多，并且是成倍减少的。

水平拆分的优点：

*  拆分规则抽象好，join 操作基本可以数据库做；
 *  不存在单库大数据，高并发的性能瓶颈；
 *  应用端改造较少；
 *  提高了系统的稳定性跟负载能力。

水平拆分的缺点：

*  拆分规则不好抽象；
 *  分片事务一致性难以解决；
 *  数据多次扩展难度大；
 *  跨库 join 性能较差。

### 4、数据切分导致的一些问题 ###

上面我们也讲了两种数据切分方式的优点和缺点，但是他们有些共同的缺点，

*  分布式事务的问题；
 *  跨节点 Join 的问题；跨节点合并排序分页的问题；
 *  多数据源管理问题。

一般来说，业务上存在着复杂 join 的场景是很难切分的，往往业务独立的易于切分。如何切分，我们遵循如下原则，

*  能不切分尽量不要切分；
 *  如果要切分一定要选择合适的切分规则，提前规划好；
 *  数据切分尽量通过数据冗余或表分组来降低跨库 Join 的可能；
 *  由于数据库中间件对数据 Join 实现的优劣难以把握，而且实现高性能难度极大，业务读取尽量少使用多表 Join。

### 5、数据源管理的问题 ###

分库分表之后，数据源的管理是系统实现的关键。

1）系统应用层面

系统应用代码层面，目前主要有两种思路，

*  客户端模式，也就是在每个应用程序模块中配置管理自己需要的一个（或者多个）数据源，直接访问各个数据库，在模块内完成数据的整合。比如可以依赖spring注解实现。
 *  中间代理模式，统一管理所有的数据源，后端数据库集群对前端应用程序透明。

考虑到系统的复杂性和扩展性，建议第二种中间代理模式。虽然短期内需要付出的成本可能会相对更大一些，但是对整个系统的扩展性来说，是非常实用的。

2）中间件层面

上面的系统层面，需要的代码实现比较复杂，中间件是在数据集群前面加一层代理，比如Cobar、Mycat等数据库中间件。实用数据库中间件，对代码层面的实现是很大的解放。

### 6、分布式事务的解决方案 ###

分库分表导致的最突出的问题就是分布式事务的处理。大家如果有兴趣可以参考下之前的文章互联网架构下的分布式技术面试要点概览中的分布式事务部分，后面如果有时间，可以单独再探讨下。

## 十、主从复制、读写分离 ##

### 1、主从复制 ###

**1）啥是主从复制**

主从复制是指：将主数据库中的DDL和DML操作通过二进制日志（BINLOG）传输到从数据库上，然后将这些日志重新执行（重做）；从而使得从数据库的数据与主数据库保持一致。

主从复制的作用：

1.  主数据库出现问题，可以切换到从数据库。
2.  可以进行数据库层面的读写分离。
3.  可以在从数据库上进行日常备份。

主从复制解决的问题：

*  数据分布：随意开始或停止复制，并在不同地理位置分布数据备份
 *  负载均衡：降低单个服务器的压力
 *  高可用和故障切换：帮助应用程序避免单点失败
 *  升级测试：可以用更高版本的MySQL作为从库

**2）主从复制工作原理**

*  在主库上把数据更高记录到二进制日志
 *  从库将主库的日志复制到自己的中继日志
 *  从库读取中继日志的事件，将其重放到从库数据中

**3）主从复制的过程**

以一主两从为例，

*  **主**：binlog线程——记录下所有改变了数据库数据的语句，放进master上的binlog中；
 *  **从**：io线程——在使用start slave 之后，负责从master上拉取 binlog 内容，放进自己的relay log中；
 *  **从**：sql执行线程——执行relay log中的语句；

如下图，

*  Binary log：主数据库的二进制日志
 *  Relay log：从服务器的中继日志

**复制过程分三步，**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 6][]

*  第一步：master在每个事务更新数据完成之前，将该操作记录串行地写入到binlog文件中。
 *  第二步：salve开启一个I/O Thread，该线程在master打开一个普通连接，主要工作是binlog dump process。如果读取的进度已经跟上了master，就进入睡眠状态并等待master产生新的事件。I/O线程最终的目的是将这些事件写入到中继日志中。
 *  第三步：SQL Thread会读取中继日志，并顺序执行该日志中的SQL事件，从而与主数据库中的数据保持一致。

### 2、读写分离有哪些解决方案？ ###

读写分离是依赖于主从复制，而主从复制又是为读写分离服务的。因为主从复制要求`slave`不能写只能读（如果对`slave`执行写操作，那么`show slave status`将会呈现`Slave_SQL_Running=NO`，此时你需要按照前面提到的手动同步一下`slave`）。

**1）方案一**

使用mysql-proxy代理

优点：直接实现读写分离和负载均衡，不用修改代码，master和slave用一样的帐号，mysql官方不建议实际生产中使用。缺点：降低性能， 不支持事务

**2）方案二**

使用AbstractRoutingDataSource+aop+annotation在dao层决定数据源。

如果采用了mybatis， 可以将读写分离放在ORM层，比如mybatis可以通过mybatis plugin拦截sql语句，所有的insert/update/delete都访问master库，所有的select 都访问salve库，这样对于dao层都是透明。 plugin实现时可以通过注解或者分析语句是读写方法来选定主从库。不过这样依然有一个问题， 也就是不支持事务， 所以我们还需要重写一下DataSourceTransactionManager， 将read-only的事务扔进读库， 其余的有读有写的扔进写库。

**3）方案三**

使用AbstractRoutingDataSource+aop+annotation在service层决定数据源，可以支持事务。

缺点：类内部方法通过this.xx()方式相互调用时，aop不会进行拦截，需进行特殊处理。

## 十、其他问题 ##

### 1、MySQL有关权限的表都有哪几个 ###

MySQL服务器通过权限表来控制用户对数据库的访问，权限表存放在mysql数据库里，由mysql\_install\_db脚本初始化。这些权限表分别user，db，table\_priv，columns\_priv和host。下面分别介绍一下这些表的结构和内容：

*  user权限表：记录允许连接到服务器的用户帐号信息，里面的权限是全局级的。
 *  db权限表：记录各个帐号在各个数据库上的操作权限。
 *  table\_priv权限表：记录数据表级的操作权限。
 *  columns\_priv权限表：记录数据列级的操作权限。
 *  host权限表：配合db权限表对给定主机上数据库级操作权限作更细致的控制。这个权限表不受GRANT和REVOKE语句的影响。

### 2、MySQL的binlog有有几种录入格式？分别有什么区别？ ###

有三种格式，statement，row和mixed。

*  statement模式下，每一条会修改数据的sql都会记录在binlog中。不需要记录每一行的变化，减少了binlog日志量，节约了IO，提高性能。由于sql的执行是有上下文的，因此在保存的时候需要保存相关的信息，同时还有一些使用了函数之类的语句无法被记录复制。
 *  row级别下，不记录sql语句上下文相关信息，仅保存哪条记录被修改。记录单元为每一行的改动，基本是可以全部记下来但是由于很多操作，会导致大量行的改动(比如alter table)，因此这种模式的文件保存的信息太多，日志量太大。
 *  mixed，一种折中的方案，普通操作使用statement记录，当无法使用statement的时候使用row。

此外，新版的MySQL中对row级别也做了一些优化，当表结构发生变化的时候，会记录语句而不是逐行记录。

### 3、**MyISAM与InnoDB区别** ###

<table> 
 <thead> 
  <tr> 
   <th>&nbsp;</th> 
   <th>MyISAM</th> 
   <th>Innodb</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>存储结构</td> 
   <td>每张表被存放在三个文件：frm-表格定义、MYD(MYData)-数据文件、MYI(MYIndex)-索引文件</td> 
   <td>所有的表都保存在同一个数据文件中（也可能是多个文件，或者是独立的表空间文件），InnoDB表的大小只受限于操作系统文件的大小，一般为2GB</td> 
  </tr> 
  <tr> 
   <td>存储空间</td> 
   <td>MyISAM可被压缩，存储空间较小</td> 
   <td>InnoDB的表需要更多的内存和存储，它会在主内存中建立其专用的缓冲池用于高速缓冲数据和索引</td> 
  </tr> 
  <tr> 
   <td>可移植性、备份及恢复</td> 
   <td>由于MyISAM的数据是以文件的形式存储，所以在跨平台的数据转移中会很方便。在备份和恢复时可单独针对某个表进行操作</td> 
   <td>免费的方案可以是拷贝数据文件、备份 binlog，或者用 mysqldump，在数据量达到几十G的时候就相对痛苦了</td> 
  </tr> 
  <tr> 
   <td>文件格式</td> 
   <td>数据和索引是分别存储的，数据<code>.MYD</code>，索引<code>.MYI</code></td> 
   <td>数据和索引是集中存储的，<code>.ibd</code></td> 
  </tr> 
  <tr> 
   <td>记录存储顺序</td> 
   <td>按记录插入顺序保存</td> 
   <td>按主键大小有序插入</td> 
  </tr> 
  <tr> 
   <td>外键</td> 
   <td>不支持</td> 
   <td>支持</td> 
  </tr> 
  <tr> 
   <td>事务</td> 
   <td>不支持</td> 
   <td>支持</td> 
  </tr> 
  <tr> 
   <td>锁支持（锁是避免资源争用的一个机制，MySQL锁对用户几乎是透明的）</td> 
   <td>表级锁定</td> 
   <td>行级锁定、表级锁定，锁定力度小并发能力高</td> 
  </tr> 
  <tr> 
   <td>SELECT</td> 
   <td>MyISAM更优</td> 
   <td>&nbsp;</td> 
  </tr> 
  <tr> 
   <td>INSERT、UPDATE、DELETE</td> 
   <td>&nbsp;</td> 
   <td>InnoDB更优</td> 
  </tr> 
  <tr> 
   <td>select count(*)</td> 
   <td>myisam更快，因为myisam内部维护了一个计数器，可以直接调取。</td> 
   <td>&nbsp;</td> 
  </tr> 
  <tr> 
   <td>索引的实现方式</td> 
   <td>B+树索引，myisam 是堆表</td> 
   <td>B+树索引，Innodb 是索引组织表</td> 
  </tr> 
  <tr> 
   <td>哈希索引</td> 
   <td>不支持</td> 
   <td>支持</td> 
  </tr> 
  <tr> 
   <td>全文索引</td> 
   <td>支持</td> 
   <td>不支持</td> 
  </tr> 
 </tbody> 
</table>

### 4、MyISAM索引与InnoDB索引的区别？ ###

*  InnoDB索引是聚簇索引，MyISAM索引是非聚簇索引。
 *  InnoDB的主键索引的叶子节点存储着行数据，因此主键索引非常高效。
 *  MyISAM索引的叶子节点存储的是行数据地址，需要再寻址一次才能得到数据。
 *  InnoDB非主键索引的叶子节点存储的是主键和其他带索引的列数据，因此查询时做到覆盖索引会非常高效。

### 5、为什么要尽量设定一个主键？ ###

主键是数据库确保数据行在整张表唯一性的保障，即使业务上本张表没有主键，也建议添加一个自增长的ID列作为主键。设定了主键之后，在后续的删改查的时候可能更加快速以及确保操作数据范围安全。

### 6、主键使用自增ID还是UUID？ ###

推荐使用自增ID，不要使用UUID。

因为在InnoDB存储引擎中，主键索引是作为聚簇索引存在的，也就是说，主键索引的B+树叶子节点上存储了主键索引以及全部的数据(按照顺序)，如果主键索引是自增ID，那么只需要不断向后排列即可，如果是UUID，由于到来的ID与原来的大小不确定，会造成非常多的数据插入，数据移动，然后导致产生很多的内存碎片，进而造成插入性能的下降。

总之，在数据量大一些的情况下，用自增主键性能会好一些。关于主键是聚簇索引，如果没有主键，InnoDB会选择一个唯一键来作为聚簇索引，如果没有唯一键，会生成一个隐式的主键。

### 7、字段为什么要求定义为not null？ ###

null值会占用更多的字节，且会在程序中造成很多与预期不符的情况。

### 8、如果要存储用户的密码散列，应该使用什么字段进行存储？ ###

密码散列，盐，用户身份证号等固定长度的字符串应该使用char而不是varchar来存储，这样可以节省空间且提高检索效率。

### **9、索引是个什么样的数据结构呢?** ###

索引的数据结构和具体存储引擎的实现有关, 在MySQL中使用较多的索引有Hash索引,B+树索引等,而我们经常使用的InnoDB存储引擎的默认索引实现为:B+树索引。

### **10、Hash索引和B+树所有有什么区别或者说优劣呢?** ###

首先要知道Hash索引和B+树索引的底层实现原理:

hash索引底层就是hash表,进行查找时,调用一次hash函数就可以获取到相应的键值,之后进行回表查询获得实际数据.B+树底层实现是多路平衡查找树.对于每一次的查询都是从根节点出发,查找到叶子节点方可以获得所查键值,然后根据查询判断是否需要回表查询数据.

那么可以看出他们有以下的不同:

*  hash索引进行等值查询更快(一般情况下),但是却无法进行范围查询.

因为在hash索引中经过hash函数建立索引之后,索引的顺序与原顺序无法保持一致,不能支持范围查询.而B+树的的所有节点皆遵循(左节点小于父节点,右节点大于父节点,多叉树也类似),天然支持范围.

*  hash索引不支持使用索引进行排序,原理同上.
 *  hash索引不支持模糊查询以及多列索引的最左前缀匹配.原理也是因为hash函数的不可预测.AAAA和AAAAB的索引没有相关性.
 *  hash索引任何时候都避免不了回表查询数据,而B+树在符合某些条件(聚簇索引,覆盖索引等)的时候可以只通过索引完成查询.
 *  hash索引虽然在等值查询上较快,但是不稳定.性能不可预测,当某个键值存在大量重复的时候,发生hash碰撞,此时效率可能极差.而B+树的查询效率比较稳定,对于所有的查询都是从根节点到叶子节点,且树的高度较低.

因此,在大多数情况下,直接选择B+树索引可以获得稳定且较好的查询速度.而不需要使用hash索引.

### **11、上面提到了B+树在满足聚簇索引和覆盖索引的时候不需要回表查询数据,什么是聚簇索引?** ###

在B+树的索引中,叶子节点可能存储了当前的key值,也可能存储了当前的key值以及整行的数据,这就是聚簇索引和非聚簇索引. 在InnoDB中,只有主键索引是聚簇索引,如果没有主键,则挑选一个唯一键建立聚簇索引.如果没有唯一键,则隐式的生成一个键来建立聚簇索引.

当查询使用聚簇索引时,在对应的叶子节点,可以获取到整行数据,因此不用再次进行回表查询.

### **12、非聚簇索引一定会回表查询吗?** ###

不一定,这涉及到查询语句所要求的字段是否全部命中了索引,如果全部命中了索引,那么就不必再进行回表查询.  
举个简单的例子,假设我们在员工表的年龄上建立了索引,那么当进行select age from employee where age < 20的查询时,在索引的叶子节点上,已经包含了age信息,不会再次进行回表查询.

### **13、在建立索引的时候,都有哪些需要考虑的因素呢?** ###

建立索引的时候一般要考虑到字段的使用频率,经常作为条件进行查询的字段比较适合.如果需要建立联合索引的话,还需要考虑联合索引中的顺序.此外也要考虑其他方面,比如防止过多的所有对表造成太大的压力.这些都和实际的表结构以及查询方式有关.

### **14、联合索引是什么?为什么需要注意联合索引中的顺序?** ###

MySQL可以使用多个字段同时建立一个索引,叫做联合索引.在联合索引中,如果想要命中索引,需要按照建立索引时的字段顺序挨个使用,否则无法命中索引.

具体原因为:

MySQL使用索引时需要索引有序,假设现在建立了"name,age,school"的联合索引,那么索引的排序为: 先按照name排序,如果name相同,则按照age排序,如果age的值也相等,则按照school进行排序.  
当进行查询时,此时索引仅仅按照name严格有序,因此必须首先使用name字段进行等值查询,之后对于匹配到的列而言,其按照age字段严格有序,此时可以使用age字段用做索引查找,,,以此类推.因此在建立联合索引的时候应该注意索引列的顺序,一般情况下,将查询需求频繁或者字段选择性高的列放在前面.此外可以根据特例的查询或者表结构进行单独的调整.

### **15、创建的索引有没有被使用到?或者说怎么才可以知道这条语句运行很慢的原因?** ###

MySQL提供了explain命令来查看语句的执行计划,MySQL在执行某个语句之前,会将该语句过一遍查询优化器,之后会拿到对语句的分析,也就是执行计划,其中包含了许多信息. 可以通过其中和索引有关的信息来分析是否命中了索引,例如possilbe\_key,key,key\_len等字段,分别说明了此语句可能会使用的索引,实际使用的索引以及使用的索引长度.

### **16、那么在哪些情况下会发生针对该列创建了索引但是在查询的时候并没有使用呢?** ###

*  使用不等于查询,
 *  列参与了数学运算或者函数
 *  在字符串like时左边是通配符.类似于'%aaa'.
 *  当mysql分析全表扫描比使用索引快的时候不使用索引.
 *  当使用联合索引,前面一个条件为范围查询,后面的即使符合最左前缀原则,也无法使用索引.

以上情况,MySQL无法使用索引。

### **16、同时有多个事务在进行会怎么样呢?** ###

多事务的并发进行一般会造成以下几个问题:

*  脏读: A事务读取到了B事务未提交的内容,而B事务后面进行了回滚.
 *  不可重复读: 当设置A事务只能读取B事务已经提交的部分,会造成在A事务内的两次查询,结果竟然不一样,因为在此期间B事务进行了提交操作.
 *  幻读: A事务读取了一个范围的内容,而同时B事务在此期间插入了一条数据.造成"幻觉".

### **17、Innodb使用的是哪种隔离级别呢?** ###

InnoDB默认使用的是可重复读隔离级别.

### **18、关于MVVC** ###

MySQL InnoDB存储引擎，实现的是基于多版本的并发控制协议——MVCC (Multi-Version Concurrency Control)

**注**：与MVCC相对的，是基于锁的并发控制，Lock-Based Concurrency Control

**MVCC最大的好处**：读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不冲突是非常重要的，极大的增加了系统的并发性能，现阶段几乎所有的RDBMS，都支持了MVCC。

*  LBCC：Lock-Based Concurrency Control，基于锁的并发控制
 *  MVCC：Multi-Version Concurrency Control，基于多版本的并发控制协议。纯粹基于锁的并发机制并发量低，MVCC是在基于锁的并发控制上的改进，主要是在读操作上提高了并发量。

### **19、在MVCC并发控制中，读操作可以分成两类：** ###

*  **快照读 (snapshot read)**：读取的是记录的可见版本 (有可能是历史版本)，不用加锁（共享读锁s锁也不加，所以不会阻塞其他事务的写）
 *  **当前读 (current read)**：读取的是记录的最新版本，并且，当前读返回的记录，都会加上锁，保证其他事务不会再并发修改这条记录。

### **20、哈希索引的优势** ###

**等值查询，**哈希索引具有绝对优势（前提是：没有大量重复键值，如果大量重复键值时，哈希索引的效率很低，因为存在所谓的哈希碰撞问题。）

### **21、哈希索引不适用的场景** ###

*  不支持范围查询
 *  不支持索引完成排序
 *  不支持联合索引的最左前缀匹配规则

通常，B+树索引结构适用于绝大多数场景。

### **22、什么是表分区？** ###

表分区，是指根据一定规则，将数据库中的一张表分解成多个更小的，容易管理的部分。从逻辑上看，只有一张表，但是底层却是由多个物理分区组成。

### **23、表分区与分表的区别** ###

**分表**：指的是通过一定规则，将一张表分解成多张不同的表。比如将用户订单记录根据时间成多个表。

**分表与分区的区别在于**：分区从逻辑上来讲只有一张表，而分表则是将一张表分解成多张表。

### **24、表分区有什么好处？** ###

*  **存储更多数据**。分区表的数据可以分布在不同的物理设备上，从而高效地利用多个硬件设备。和单个磁盘或者文件系统相比，可以存储更多数据
 *  **优化查询**。在where语句中包含分区条件时，可以只扫描一个或多个分区表来提高查询效率；涉及sum和count语句时，也可以在多个分区上并行处理，最后汇总结果。
 *  **分区表更容易维护**。例如：想批量删除大量数据可以清除整个分区。
 *  **避免某些特殊的瓶颈**，例如InnoDB的单个索引的互斥访问，ext3问价你系统的inode锁竞争等。

### **25、分区表的限制因素** ###

*  一个表最多只能有1024个分区
 *  MySQL5.1中，分区表达式必须是整数，或者返回整数的表达式。在MySQL5.5中提供了非整数表达式分区的支持。
 *  如果分区字段中有主键或者唯一索引的列，那么多有主键列和唯一索引列都必须包含进来。即：分区字段要么不包含主键或者索引列，要么包含全部主键和索引列。
 *  分区表中无法使用外键约束
 *  MySQL的分区适用于一个表的所有数据和索引，不能只对表数据分区而不对索引分区，也不能只对索引分区而不对表分区，也不能只对表的一部分数据分区。

### **26、如何判断当前MySQL是否支持分区？** ###

命令：show variables like '%partition%' 运行结果：have\_partintioning 的值为YES，表示支持分区。

### **27、MySQL支持的分区类型有哪些？** ###

*  **RANGE分区**： 这种模式允许将数据划分不同范围。例如可以将一个表通过年份划分成若干个分区
 *  **LIST分区**： 这种模式允许系统通过预定义的列表的值来对数据进行分割。按照List中的值分区，与RANGE的区别是，range分区的区间范围值是连续的。
 *  **HASH分区** ：这中模式允许通过对表的一个或多个列的Hash Key进行计算，最后通过这个Hash码不同数值对应的数据区域进行分区。例如可以建立一个对表主键进行分区的表。
 *  **KEY分区 **：上面Hash模式的一种延伸，这里的Hash Key是MySQL系统产生的。

### **28、行级锁定的优点：** ###

*  1、当在许多线程中访问不同的行时只存在少量锁定冲突。
 *  2、回滚时只有少量的更改
 *  3、可以长时间锁定单一的行。

### **29、行级锁定的缺点：** ###

*  比页级或表级锁定占用更多的内存。
 *  当在表的大部分中使用时，比页级或表级锁定速度慢，因为你必须获取更多的锁。
 *  如果你在大部分数据上经常进行GROUP BY操作或者必须经常扫描整个表，比其它锁定明显慢很多。
 *  用高级别锁定，通过支持不同的类型锁定，你也可以很容易地调节应用程序，因为其锁成本小于行级锁定。

### **30、MySQL优化** ###

*  开启查询缓存，优化查询
 *  explain你的select查询，这可以帮你分析你的查询语句或是表结构的性能瓶颈。EXPLAIN 的查询结果还会告诉你你的索引主键被如何利用的，你的数据表是如何被搜索和排序的
 *  当只要一行数据时使用limit 1，MySQL数据库引擎会在找到一条数据后停止搜索，而不是继续往后查少下一条符合记录的数据
 *  为搜索字段建索引
 *  使用 ENUM 而不是 VARCHAR。如果你有一个字段，比如“性别”，“国家”，“民族”，“状态”或“部门”，你知道这些字段的取值是有限而且固定的，那么，你应该使用 ENUM 而不是VARCHAR
 *  Prepared StatementsPrepared Statements很像存储过程，是一种运行在后台的SQL语句集合，我们可以从使用 prepared statements 获得很多好处，无论是性能问题还是安全问题。
 *  Prepared Statements 可以检查一些你绑定好的变量，这样可以保护你的程序不会受到“SQL注入式”攻击
 *  垂直分表
 *  选择正确的存储引擎

### **31、key和index的区别** ###

*  key 是数据库的物理结构，它包含两层意义和作用，一是约束（偏重于约束和规范数据库的结构完整性），二是索引（辅助查询用的）。包括primary key, unique key, foreign key 等
 *  index是数据库的物理结构，它只是辅助查询的，它创建时会在另外的表空间（mysql中的innodb表空间）以一个类似目录的结构存储。索引要分类的话，分为前缀索引、全文本索引等；

### **32、数据库表创建注意事项** ###

**1）字段名及字段配制合理性**

*  剔除关系不密切的字段；
 *  字段命名要有规则及相对应的含义（不要一部分英文，一部分拼音，还有类似a.b.c这样不明含义的字段）；
 *  字段命名尽量不要使用缩写（大多数缩写都不能明确字段含义）；
 *  字段不要大小写混用（想要具有可读性，多个英文单词可使用下划线形式连接）；
 *  字段名不要使用保留字或者关键字；
 *  保持字段名和类型的一致性；
 *  慎重选择数字类型；
 *  给文本字段留足余量；

**2）系统特殊字段处理及建成后建议**

*  添加删除标记（例如操作人、删除时间）；
 *  建立版本机制；

**3）表结构合理性配置**

*  多型字段的处理，就是表中是否存在字段能够分解成更小独立的几部分（例如：人可以分为男人和女人）；
 *  多值字段的处理，可以将表分为三张表，这样使得检索和排序更加有调理，且保证数据的完整性！

**4）其它建议**

*  对于大数据字段，独立表进行存储，以便影响性能（例如：简介字段）；
 *  使用varchar类型代替char，因为varchar会动态分配长度，char指定长度是固定的；
 *  给表创建主键，对于没有主键的表，在查询和索引定义上有一定的影响；
 *  避免表字段运行为null，建议设置默认值（例如：int类型设置默认值为0）在索引查询上，效率立显；
 *  建立索引，最好建立在唯一和非空的字段上，建立太多的索引对后期插入、更新都存在一定的影响（考虑实际情况来创建）；

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70]: /images/20221120/38547180fb0b4a5e8e485fdbe2bb2235.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 1]: /images/20221120/d6be85da06f541b1a07ccbdb946e145a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20201111142722604.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20201111142856347.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20201111143116213.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/20201111143227619.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 6]: https://img-blog.csdnimg.cn/20201111164503826.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg==,size_16,color_FFFFFF,t_70