系列目录

前言

大家好，我是老马。

mysql 使我们日常开发中常用的数据库框架。

面试中自然出现频率也比较高，对常见问题进行整理，便于平时查阅收藏。

索引

（1）什么是索引?

索引是一种数据结构，可以帮助我们快速的进行数据的查找。

比如哈希，二叉树，B 树， B+ 树，倒排索引等等。

（2）索引是个什么样的数据结构呢?

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

（3）为什么使用索引？

通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。

可以大大加快数据的检索速度，这也是创建索引的最主要的原因。

帮助服务器避免排序和临时表。

将随机IO变为顺序IO。

可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。

（4）Innodb为什么要用自增id作为主键？

如果表使用自增主键，那么每次插入新的记录，记录就会顺序添加到当前索引节点的后续位置，当一页写满，就会自动开辟一个新的页。

如果使用非自增主键（如果身份证号或学号等），由于每次插入主键的值近似于随机，因此每次新纪录都要被插到现有索引页得中间某个位置，频繁的移动、分页操作造成了大量的碎片，得到了不够紧凑的索引结构，后续不得不通过OPTIMIZE TABLE（optimize table）来重建表并优化填充页面。

ps: 避免造成大量的内存碎片。

（5）Hash 索引和 B+ 树索引有什么区别或者说优劣呢?

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

hash 索引底层就是 hash 表，进行查找时，调用一次 hash 函数就可以获取到相应的键值，之后进行回表查询获得实际数据。

B+ 树底层实现是多路平衡查找树。对于每一次的查询都是从根节点出发，查找到叶子节点方可以获得所查键值，然后根据查询判断是否需要回表查询数据。

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

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

因为在 hash 索引中经过 hash 函数建立索引之后，索引的顺序与原顺序无法保持一致，不能支持范围查询。

而 B+ 树的的所有节点皆遵循(左节点小于父节点，右节点大于父节点，多叉树也类似)，天然支持范围。

hash 索引不支持使用索引进行排序，原理同上。

hash 索引不支持模糊查询以及多列索引的最左前缀匹配。原理也是因为 hash 函数的不可预测。

hash索引任何时候都避免不了回表查询数据,而B+树在符合某些条件(聚簇索引,覆盖索引等)的时候可以只通过索引完成查询

hash 索引虽然在等值查询上较快，但是不稳定。性能不可预测，当某个键值存在大量重复的时候，发生 hash 碰撞，此时效率可能极差。

而 B+ 树的查询效率比较稳定，对于所有的查询都是从根节点到叶子节点，且树的高度较低。

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

（6）什么是聚簇索引

聚簇索引就是按照每张表的主键构造一棵B+树，同时叶子节点中存放的就是整张表的行记录数据。

在 InnoDB 中，只有主键索引是聚簇索引，如果没有主键，则挑选一个唯一键建立聚簇索引。

如果没有唯一键，则 MySQL 自动为 InnoDB 表生成一个隐含字段来建立聚簇索引，这个字段长度为6个字节，类型为长整形。

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

（7）说一说索引的底层实现？

Hash 索引

基于哈希表实现，只有精确匹配索引所有列的查询才有效，对于每一行数据，存储引擎都会对所有的索引列计算一个哈希码（hash code），并且Hash索引将所有的哈希码存储在索引中，同时在索引表中保存指向每个数据行的指针。

HASH

B-Tree 索引（MySQL使用B+Tree）

B-Tree能加快数据的访问速度，因为存储引擎不再需要进行全表扫描来获取数据，数据分布在各个节点之中。

B-TREE

B+Tree索引

是B-Tree的改进版本，同时也是数据库索引所采用的存储结构。

数据都在叶子节点上，并且增加了顺序访问指针，每个叶子节点都指向相邻的叶子节点的地址。

相比B-Tree来说，进行范围查找时只需要查找两个节点，进行遍历即可。

而B-Tree需要获取所有节点，相比之下B+Tree效率更高。

B+ tree 性质：

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

B+ TREE

（8）索引有哪些优缺点？

索引的优点

可以大大加快数据的检索速度，这也是创建索引的最主要的原因。

通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。

索引的缺点

时间方面：创建索引和维护索引要耗费时间，具体地，当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，会降低增/改/删的执行效率；

空间方面：索引需要占物理空间。

（9）聚簇索引和非聚簇索引的区别

聚簇索引的叶子节点存放的是主键值和数据行，支持覆盖索引

非聚簇索引的叶子节点存放的是主键值或数据记录的地址（InnoDB辅助索引的data域存储相应记录主键的值，MyISAM辅助索引的data域保存数据记录的地址）

（10）MyISAM和InnoDB实现B+树索引方式的区别是什么？

MyISAM，B+Tree叶节点的data域存放的是数据记录的地址，在索引检索的时候，首先按照B+Tree搜索算法搜索索引，如果指定的key存在，则取出其data域的值，然后以data域的值为地址读取相应的数据记录，这被称为“非聚簇索引”

InnoDB，其数据文件本身就是索引文件，相比MyISAM，索引文件和数据文件是分离的，其表数据文件本身就是按B+Tree组织的一个索引结构，树的节点data域保存了完整的数据记录，这个索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引，这被称为“聚簇索引”或者聚集索引，而其余的索引都作为辅助索引，辅助索引的data域存储相应记录主键的值而不是地址，这也是和MyISAM不同的地方。

在根据主键索引搜索时，直接找到key所在的节点即可取出数据；根据辅助索引查找时，则需要先取出主键的值，再走一遍主索引。

因此，在设计表的时候，不建议使用过长的字段为主键，也不建议使用非单调的字段作为主键，这样会造成主索引频繁分裂。

总结：InnoDB 主键索引使用的是聚簇索引，MyISAM 不管是主键索引，还是二级索引使用的都是非聚簇索引。

（11）MySQL中有几种索引类型，可以简单说说吗？

FULLTEXT ：即为全文索引，目前只有MyISAM引擎支持。其可以在CREATE TABLE ，ALTER TABLE ，CREATE INDEX 使用，不过目前只有 CHAR、VARCHAR ，TEXT 列上可以创建全文索引。

HASH ：由于HASH的唯一（几乎100%的唯一）及类似键值对的形式，很适合作为索引。HASH索引可以一次定位，不需要像树形索引那样逐层查找,因此具有极高的效率。但是，这种高效是有条件的，即只在“=”和“in”条件下高效，对于范围查询、排序及组合索引仍然效率不高。

BTREE ：BTREE索引就是一种将索引值按一定的算法，存入一个树形的数据结构中（二叉树），每次查询都是从树的入口root开始，依次遍历node，获取leaf。这是MySQL里默认和最常用的索引类型。

RTREE ：RTREE在MySQL很少使用，仅支持geometry数据类型，支持该类型的存储引擎只有MyISAM、BDb、InnoDb、NDb、Archive几种。相对于BTREE，RTREE的优势在于范围查找。

（12）覆盖索引是什么？

如果一个索引包含（或者说覆盖）所有需要查询的字段的值，我们就称之为“覆盖索引”。

我们知道在InnoDB存储引擎中，如果不是主键索引，叶子节点存储的是主键值。最终还是要“回表”，也就是要通过主键再查找一次,这样就会比较慢。

覆盖索引就是把要查询出的列和索引是对应的，不做回表操作！

（13）非聚簇索引一定会回表查询吗?

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

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

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

MySQL 可以使用多个字段同时建立一个索引，叫做联合索引。

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

具体原因为：

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

当进行查询时，此时索引仅仅按照 name 严格有序，因此必须首先使用 name 字段进行等值查询，之后对于匹配到的列而言，其按照 age 字段严格有序，此时可以使用 age 字段用做索引查找，以此类推。

因此在建立联合索引的时候应该注意索引列的顺序，一般情况下，将查询需求频繁或者字段选择性高的列放在前面。

此外可以根据特例的查询或者表结构进行单独的调整。

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

MySQL 提供了 explain 命令来查看语句的执行计划，MySQL 在执行某个语句之前，会将该语句过一遍查询优化器，之后会拿到对语句的分析，也就是执行计划，其中包含了许多信息。

可以通过其中和索引有关的信息来分析是否命中了索引，例如possilbe_key，key，key_len等字段，分别说明了此语句可能会使用的索引，实际使用的索引以及使用的索引长度。

“执行计划”中需要知道的几个“关键字”

id：编号

select_type：查询类型

table：表

type：类型

possible_keys：预测用到的索引

key：实际使用的索引

key_len：实际使用索引的长度

ref：表之间的引用

rows：通过索引查询到的数据量

Extra：额外的信息

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

使用不等于查询

列参与了数学运算或者函数

在字符串 like 时左边是通配符。类似于’%aaa’。

当 mysql 分析全表扫描比使用索引快的时候不使用索引。

当使用联合索引，前面一个条件为范围查询，后面的即使符合最左前缀原则，也无法使用索引。

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

（17）为什么Mysql用B+树做索引而不用B-树或红黑树、二叉树

主要原因：B+树只要遍历叶子节点就可以实现整棵树的遍历，而且在数据库中基于范围的查询是非常频繁的，而B树只能中序遍历所有节点，效率太低。

B-tree：

B+树的磁盘读写代价更低：

B+树的内部节点并没有指向关键字具体信息的指针，因此其内部节点相对B(B-)树更小，如果把所有同一内部节点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多，一次性读入内存的需要查找的关键字也就越多，相对IO读写次数就降低了。

由于B+树的数据都存储在叶子结点中，分支结点均为索引，方便扫库，只需要扫一遍叶子结点即可，但是B树因为其分支结点同样存储着数据，我们要找到具体的数据，需要进行一次中序遍历按序来扫，所以B+树更加适合在区间查询的情况，所以通常B+树用于数据库索引。

Hash：

虽然可以快速定位，但是没有顺序，IO复杂度高；

基于Hash表实现，只有Memory存储引擎显式支持哈希索引；

适合等值查询，如=、in()、<=>，不支持范围查询；

因为不是按照索引值顺序存储的，就不能像B+Tree索引一样利用索引完成排序；

Hash索引在查询等值时非常快；

因为Hash索引始终索引的所有列的全部内容，所以不支持部分索引列的匹配查找；

如果有大量重复键值得情况下，哈希索引的效率会很低，因为存在哈希碰撞问题。

二叉树

树的高度不均匀，不能自平衡，查找效率跟数据有关（树的高度），并且IO代价高。

红黑树

树的高度随着数据量增加而增加，IO代价高。

（18）MySQL索引种类

普通索引、唯一索引(主键索引、唯一索引)、联合索引、全文索引、空间索引

（19）索引在什么情况下遵循最左前缀的规则？

在建立了联合索引的前提条件下，数据库会一直从左向右的顺序依次查找，直到遇到了范围查询(>,<,between,like等)

事务

（1）什么是事务?

事务是一系列的数据库操作，他们要符合 ACID 特性，事务是数据库应用的基本单位。MySQL 事务主要用于处理操作量大，复杂度高的数据。

（2）ACID 是什么? 可以详细说一下吗?

A=Atomicity：原子性，就是要么全部成功，要么全部失败。不可能只执行一部分操作。

C=Consistency：一致性，系统(数据库)总是从一个一致性的状态转移到另一个一致性的状态，不会存在中间状态。

I=Isolation：隔离性，通常来说：一个事务在完全提交之前，对其他事务是不可见的.注意前面的通常来说加了红色，意味着有例外情况。

D=Durability：持久性，一旦事务提交，那么就永远是这样子了，哪怕系统崩溃也不会影响到这个事务的结果。

3）MySQL中为什么要有事务回滚机制？

而在 MySQL 中，恢复机制是通过回滚日志（undo log）实现的，所有事务进行的修改都会先记录到这个回滚日志中，然后在对数据库中的对应行进行写入。

当事务已经被提交之后，就无法再次回滚了。

回滚日志作用：

能够在发生错误或者用户执行 ROLLBACK 时提供回滚相关的信息
在整个系统发生崩溃、数据库进程直接被杀死后，当用户再次启动数据库进程时，还能够立刻通过查询回滚日志将之前未完成的事务进行回滚，这也就需要回滚日志必须先于数据持久化到磁盘上，是我们需要先写日志后写数据库的主要原因。

（4）数据库并发事务会带来哪些问题？

数据库并发事务会带来脏读、幻读、丢弃更改、不可重复读这四个常见问题，其中：

脏读：A 事务读取到了 B 事务未提交的内容，但是之后B事务满足一致性等特性而做了回滚操作，那么读取事务得到的结果就是脏数据了。

幻读：A 事务读取了一个范围的内容，而同时 B 事务在此期间插入（删除）了一条数据。造成”幻觉”。

丢弃修改：两个写事务T1 T2同时对A=0进行递增操作，结果T2覆盖T1，导致最终结果是1 而不是2，事务被覆盖

不可重复读：当设置T2事务只能读取 T1 事务已经提交的部分，T2 读取一个数据，然后T1 对该数据做了修改。如果 T2 再次读取这个数据，此时读取的结果和第一次读取的结果不同。

当设置A事务只能读取 B 事务已经提交的部分，会造成在 A 事务内的两次查询，结果竟然不一样，因为在此期间 B 事务进行了提交操作。

脏读图解：

脏读图解

第一个事务首先读取 var 变量为50，接着准备更新为100的时，并未提交，第二个事务已经读取var为100，此时第一个事务做了回滚。

最终第二个事务读取的 var 和数据库的 var 不一样。

幻读图解：

幻读图解

T1 读取某个范围的数据，T2 在这个范围内插入新的数据，T1 再次读取这个范围的数据，此时读取的结果和和第一次读取的结果不同。

丢弃修改图解：

丢弃修改图解

T1 和 T2 两个事务都对一个数据进行修改，T1 先修改，T2 随后修改，T2 的修改覆盖了 T1 的修改。

例如：事务1读取某表中的数据A=50，事务2也读取A=50，事务1修改A=A+50，事务2也修改A=A+50，最终结果A=100，事务1的修改被丢失。

不可重复读图解：

不可重复读图解

T2 读取一个数据，T1 对该数据做了修改。

如果 T2 再次读取这个数据，此时读取的结果和第一次读取的结果不同。

（5）怎么解决这些问题呢?MySQL 的事务隔离级别了解吗?

MySQL 的四种隔离级别如下：

未提交读(READ UNCOMMITTED)：事务中发生了修改，即使没有提交，其他事务也是可见的，比如对于一个数A原来50修改为100，但是我还没有提交修改，另一个事务看到这个修改，而这个时候原事务发生了回滚，这时候A还是50，但是另一个事务看到的A是100.可能会导致脏读、幻读或不可重复读

已提交读(READ COMMITTED)：对于一个事务从开始直到提交之前，所做的任何修改是其他事务不可见的，举例就是对于一个数A原来是50，然后提交修改成100，这个时候另一个事务在A提交修改之前，读取的A是50，刚读取完，A就被修改成100，这个时候另一个事务再进行读取发现A就突然变成100了；可以阻止脏读，但是幻读或不可重复读仍有可能发生

可重复读(REPEATABLE READ)：就是对一个记录读取多次的记录是相同的，比如对于一个数A读取的话一直是A，前后两次读取的A是一致的；可以阻止脏读和不可重复读，但幻读仍有可能发生

可串行化(SERIALIZABLE)：在并发情况下，和串行化的读取的结果是一致的，没有什么不同，比如不会发生脏读和幻读；该级别可以防止脏读、不可重复读以及幻读

隔离级别	脏读	不可重复读	幻影读
READ UNCOMMITTED 未提交读	√	√	√
READ COMMITTED 已提交读	×	√	√
REPEATABLE READ 可重复读	×	×	√
SERIALIZABLE 可串行化	×	×	×

（6）Innodb 使用的是哪种隔离级别呢?

MySQL InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ（可重复读）

原因：与 SQL 标准不同的地方在于InnoDB 存储引擎在 REPEATABLE-READ（可重读）事务隔离级别下使用的是 Next-Key Lock 锁算法，因此可以避免幻读的产生，这与其他数据库系统(如 SQL Server)是不同的。

所以说 InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ（可重读）已经可以完全保证事务的隔离性要求，即达到了 SQL标准的SERIALIZABLE(可串行化)隔离级别。

InnoDB 存储引擎在分布式事务的情况下一般会用到SERIALIZABLE(可串行化)隔离级别。

（7）不可重复读和幻读区别是什么？可以举个例子吗？

不可重复读的重点是修改，幻读的重点在于新增或者删除。

例1（同样的条件, 你读取过的数据, 再次读取出来发现值不一样了）：事务1中的A先生读取自己的工资为 1000的操作还没完成，事务2中的B先生就修改了A的工资为2000，导致A再读自己的工资时工资变为 2000；这就是不可重复读。

例2（同样的条件, 第1次和第2次读出来的记录数不一样）：假某工资单表中工资大于3000的有4人，事务1读取了所有工资大于3000的人，共查到4条记录，这时事务2 又插入了一条工资大于3000的记录，事务1再次读取时查到的记录就变为了5条，这样就导致了幻读。

MVCC熟悉吗，它的底层原理？

MVCC 多版本并发控制,它是通过读取历史版本的数据，来降低并发事务冲突，从而提高并发性能的一种机制。

MVCC 需要关注这几个知识点：

事务版本号

表的隐藏列

undo log

read view

可以看我这篇文章哈：一文彻底读懂MySQL事务的四大隔离级别

MVCC

Innodb的事务与日志的实现方式

有多少种日志

innodb两种日志redo和undo。

日志的存放形式

redo：在页修改的时候，先写到 redo log buffer 里面，然后写到 redo log 的文件系统缓存里面(fwrite)，然后再同步到磁盘文件（ fsync）。

Undo：在 MySQL5.5 之前， undo 只能存放在 ibdata文件里面， 5.6 之后，可以通过设置 innodb_undo_tablespaces 参数把 undo log 存放在 ibdata之外。

事务是如何通过日志来实现的

因为事务在修改页时，要先记 undo，在记 undo 之前要记 undo 的 redo，然后修改数据页，再记数据页修改的 redo。 Redo（里面包括 undo 的修改）一定要比数据页先持久化到磁盘。

当事务需要回滚时，因为有 undo，可以把数据页回滚到前镜像的状态，崩溃恢复时，如果 redo log 中事务没有对应的 commit 记录，那么需要用 undo把该事务的修改回滚到事务开始之前。

如果有 commit 记录，就用 redo 前滚到该事务完成时并提交掉。

锁

（1）对 MySQL 的锁了解吗?

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

就像酒店的房间,如果大家随意进出,就会出现多人抢夺同一个房间的情况,而在房间上装上锁,申请到钥匙的人才可以入住并且将房间锁起来,其他人只有等他使用完毕才可以再次使用.

（2）MySQL 锁的分类

Mysql 中锁的分类按照不同类型的划分可以分成不同的锁：

按照锁的粒度划分可以分成：

行锁
表锁
页锁

按照使用的方式划分可以分为：

共享锁
排它锁

按照思想的划分：

乐观锁
悲观锁

（3）行级锁、表级锁、页级锁的描述与特点

行级锁：

描述：行级锁是mysql中锁定粒度最细的一种锁。表示只针对当前操作的行进行加锁。行级锁能大大减少数据库操作的冲突，其加锁粒度最小，但加锁的开销也最大。行级锁分为共享锁和排他锁

特点：开销大，加锁慢，会出现死锁。发生锁冲突的概率最低，并发度也最高。

表级锁：

描述：表级锁是mysql中锁定粒度最大的一种锁，表示对当前操作的整张表加锁，它实现简单，资源消耗较少，被大部分mysql引擎支持。最常使用的MyISAM与InnoDB都支持表级锁定。表级锁定分为表共享读锁（共享锁）与表独占写锁（排他锁）

特点：开销小，加锁快，不会出现死锁。发生锁冲突的概率最高，并发度也最低。

页级锁：

描述：页级锁是 MySQL 中锁定粒度介于行级锁和表级锁中间的一种锁。表级锁速度快，但冲突多，行级冲突少，但速度慢。因此，采取了折衷的页级锁，一次锁定相邻的一组记录。BDB 支持页级锁。

特点：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。

（4）共享锁、排他锁的描述

共享锁：

描述：

共享锁又称读锁，是读取操作创建的锁。其他用户可以并发读取数据，但任何事务都不能对数据进行修改（获取数据上的排他锁），直到已释放所有共享锁。

如果事务T对数据A加上共享锁后，则其他事务只能对A再加共享锁，不能加排他锁。

获准共享锁的事务只能读数据，不能修改数据。

用法：

SELECT … LOCK IN SHARE MODE;

在查询语句后面增加LOCK IN SHARE MODE，MySQL 就会对查询结果中的每行都加共享锁，当没有其他线程对查询结果集中的任何一行使用排他锁时，可以成功申请共享锁，否则会被阻塞。

其他线程也可以读取使用了共享锁的表，而且这些线程读取的是同一个版本的数据。

排他锁：

描述：

排他锁又称写锁、独占锁，如果事务T对数据A加上排他锁后，则其他事务不能再对A加任何类型的封锁。获准排他锁的事务既能读数据，又能修改数据。

用法：

SELECT … FOR UPDATE;

在查询语句后面增加FOR UPDATE，MySQL 就会对查询结果中的每行都加排他锁，当没有其他线程对查询结果集中的任何一行使用排他锁时，可以成功申请排他锁，否则会被阻塞。

用上面的例子来说就是用户的行为有两种,一种是来看房,多个用户一起看房是可以接受的。

一种是真正的入住一晚,在这期间,无论是想入住的还是想看房的都不可以.

（5）悲观锁与乐观锁

乐观锁(Optimistic Lock)

假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。

乐观锁不能解决脏读的问题。

乐观锁, 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。

乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于 write_condition 机制的其实都是提供的乐观锁。

悲观锁(Pessimistic Lock)

假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。

悲观锁，顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。

传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

（6）数据库悲观锁和乐观锁的原理和应用场景分别有什么？

悲观锁，先获取锁，再进行业务操作，一般就是利用类似 SELECT … FOR UPDATE 这样的语句，对数据加锁，避免其他事务意外修改数据。

当数据库执行SELECT … FOR UPDATE时会获取被select中的数据行的行锁，select for update获取的行锁会在当前事务结束时自动释放，因此必须在事务中使用。

乐观锁，先进行业务操作，只在最后实际更新数据时进行检查数据是否被更新过。

Java 并发包中的 AtomicFieldUpdater 类似，也是利用 CAS 机制，并不会对数据加锁，而是通过对比数据的时间戳或者版本号，来实现乐观锁需要的版本判断。

（7）MySQL常用存储引擎的锁机制？

MyISAM和MEMORY采用表级锁(table-level locking)

BDB采用页面锁(page-level locking)或表级锁，默认为页面锁

InnoDB支持行级锁(row-level locking)和表级锁,默认为行级锁

（8）InnoDB 存储引擎有几种锁算法？

Record Lock — 单个行记录上的锁；

Gap Lock — 间隙锁，锁定一个范围，不包括记录本身；

Next-Key Lock — 锁定一个范围，包括记录本身。

（9）什么是死锁？

是指二个或者二个以上的进程在执行时候，因为争夺资源造成相互等待的现象，进程一直处于等待中，无法得到释放，这种状态就叫做死锁。

（10）死锁出现的案列？

批量入库，存在则更新，不存在则插入，insert into tab(xx,xx) on duplicate key update xx='xx'。

（11）如何处理死锁？

通过 innodblockwait_timeout 来设置超时时间，一直等待直到超时

发起死锁检测，发现死锁之后，主动回滚死锁中的事务，不需要其他事务继续

（12）如何避免死锁？

为了在单个innodb表上执行多个并发写入操作时避免死锁，可以在事务开始时，通过为预期要修改行，使用select …for update语句来获取必要的锁，即使这些行的更改语句是在之后才执行的在事务中，如果要更新记录，应该直接申请足够级别的锁，即排他锁，而不应先申请共享锁，更新时在申请排他锁。
因为这时候当用户在申请排他锁时，其他事务可能又已经获得了相同记录的共享锁
如果事务需要修改或锁定多个表，则应在每个事务中以相同的顺序使用加锁语句。在应用中，如果不同的程序会并发获取多个表，应尽量约定以相同的顺序来访问表，这样可以大大降低产生死锁的机会
通过 select …lock in share mode 获取行的读锁后，如果当前事务在需要对该记录进行更新操作，则很有可能造成死锁
改变事务隔离级别

（13）Innodb 默认是如何对待死锁的？

innodb 默认是使用设置死锁时间来让死锁超时的策略，默认 innodblockwait_timeout 设置的时长是 50s

（14）如何开启死锁检测？

设置 innodbdeadlockdetect 设置为on可以主动检测死锁，在innodb中这个值默认就是on开启的状态

（15）什么是全局锁？它的应用场景有哪些？

全局锁就是对整个数据库实例加锁，它的典型使用场景就是做全库逻辑备份，这个命令可以使用整个库处于只读状态，使用该命令之后，数据更新语句，数据定义语句，更新类事务的提交语句等操作都会被阻塞。

（16）使用全局锁会导致的问题？

如果在主库备份，在备份期间不能更新，业务停止，所以更新业务会处于等待状态

如果在从库备份，在备份期间不能执行主库同步的 binlog，导致主从延迟

（17）优化锁方面你有什么建议？

尽量使用较低的隔离级别。

精心设计索引，并尽量使用索引访问数据，使加锁更精确，从而减少锁冲突的机会。

选择合理的事务大小，小事务发生锁冲突的几率也更小。

给记录集显示加锁时，最好一次性请求足够级别的锁。比如要修改数据的话，最好直接申请排他锁，而不是先申请共享锁，修改时再请求排他锁，这样容易产生死锁。

不同的程序访问一组表时，应尽量约定以相同的顺序访问各表，对一个表而言，尽可能以固定的顺序存取表中的行。这样可以大大减少死锁的机会。

尽量用相等条件访问数据，这样可以避免间隙锁对并发插入的影响。

不要申请超过实际需要的锁级别。

除非必须，查询时不要显示加锁。 MySQL 的 MVCC 可以实现事务中的查询不用加锁，优化事务性能；MVCC 只在 COMMITTED READ（读提交）和 REPEATABLE READ（可重复读）两种隔离级别下工作。

对于一些特定的事务，可以使用表锁来提高处理速度或减少死锁的可能。

四、存储引擎相关

（1）MySQL 支持哪些存储引擎?

MySQL 支持多种存储引擎，比如 InnoDB，MyISAM，Memory，Archive 等等。

在大多数的情况下，直接选择使用 InnoDB 引擎都是最合适的，InnoDB 也是 MySQL 的默认存储引擎。

（2）InnoDB 和 MyISAM 有什么区别?

InnoDB

是 MySQL 默认的事务型存储引擎，只有在需要它不支持的特性时，才考虑使用其它存储引擎。

实现了四个标准的隔离级别，默认级别是可重复读(REPEATABLE READ)。

在可重复读隔离级别下，通过多版本并发控制(MVCC)+ 间隙锁(Next-Key Locking)防止幻影读。

主索引是聚簇索引，在索引中保存了数据，从而避免直接读取磁盘，因此对查询性能有很大的提升。

内部做了很多优化，包括从磁盘读取数据时采用的可预测性读、能够加快读操作并且自动创建的自适应哈希索引、能够加速插入操作的插入缓冲区等。

支持真正的在线热备份。其它存储引擎不支持在线热备份，要获取一致性视图需要停止对所有表的写入，而在读写混合场景中，停止写入可能也意味着停止读取。

MyISAM

设计简单，数据以紧密格式存储。对于只读数据，或者表比较小、可以容忍修复操作，则依然可以使用它。

提供了大量的特性，包括压缩表、空间数据索引等。

不支持事务。

不支持行级锁，只能对整张表加锁，读取时会对需要读到的所有表加共享锁，写入时则对表加排它锁。但在表有读取操作的同时，也可以往表中插入新的记录，这被称为并发插入(CONCURRENT INSERT)。

总结：

InnoDB 支持事物，而 MyISAM 不支持事物
InnoDB 支持行级锁，表锁，而 MyISAM 支持表级锁
InnoDB 支持 MVCC，而 MyISAM 不支持
InnoDB 支持外键，而 MyISAM 不支持
InnoDB 5.7之前不支持全文索引，而 MyISAM 支持
InnoDB 必须有主键，没有指定会默认生成一个隐藏列作为主键，而MyISAM可以没有

（3）你了解MySQL的内部构造吗？一般可以分为哪两个部分？

可以分为服务层和存储引擎层两部分，其中：

服务层包括连接器、查询缓存、分析器、优化器、执行器等，涵盖MySQL的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等。

存储引擎层负责数据的存储和提取。其架构模式是插件式的，支持InnoDB、MyISAM、Memory等多个存储引擎。

现在最常用的存储引擎是InnoDB，它从MySQL5.5.5版本开始成为了默认的存储引擎。

mysql struct

（4）说一下MySQL是如何执行一条SQL的？具体步骤有哪些？

Server 层按顺序执行 sql 的步骤为：

客户端请求->
连接器（验证用户身份，给予权限） ->
查询缓存（存在缓存则直接返回，不存在则执行后续操作）->
分析器（对SQL进行词法分析和语法分析操作） ->
优化器（主要对执行的sql优化选择最优的执行方案方法） ->
执行器（执行时会先看用户是否有执行权限，有才去使用这个引擎提供的接口）->
去引擎层获取数据返回（如果开启查询缓存则会缓存查询结果）

简单概括：

连接器：管理连接、权限验证；

查询缓存：命中缓存则直接返回结果；

分析器：对SQL进行词法分析、语法分析；（判断查询的SQL字段是否存在也是在这步）

优化器：执行计划生成、选择索引；

执行器：操作引擎、返回结果；

存储引擎：存储数据、提供读写接口。

SQL 的执行顺序？

SELECT DISTINCT
    < select_list >
FROM
    < left_table > < join_type >
JOIN < right_table > ON < join_condition >
WHERE
    < where_condition >
GROUP BY
    < group_by_list >
HAVING
    < having_condition >
ORDER BY
    < order_by_condition >
LIMIT < limit_number >

它的执行顺序你知道吗？这道题就给你一个回答。

FROM 连接

首先，对 SELECT 语句执行查询时，对FROM 关键字两边的表执行连接，会形成笛卡尔积，这时候会产生一个虚表VT1(virtual table)

ON 过滤

然后对 FROM 连接的结果进行 ON 筛选，创建 VT2，把符合记录的条件存在 VT2 中。

JOIN 连接

第三步，如果是 OUTER JOIN(left join、right join) ，那么这一步就将添加外部行，如果是 left join 就把 ON 过滤条件的左表添加进来，如果是 right join ，就把右表添加进来，从而生成新的虚拟表 VT3。

WHERE 过滤

第四步，是执行 WHERE 过滤器，对上一步生产的虚拟表引用 WHERE 筛选，生成虚拟表 VT4。

GROUP BY

根据 group by 字句中的列，会对 VT4 中的记录进行分组操作，产生虚拟机表 VT5。果应用了group by，那么后面的所有步骤都只能得到的 VT5 的列或者是聚合函数（count、sum、avg等）。

HAVING

紧跟着 GROUP BY 字句后面的是 HAVING，使用 HAVING 过滤，会把符合条件的放在 VT6

SELECT

第七步才会执行 SELECT 语句，将 VT6 中的结果按照 SELECT 进行刷选，生成 VT7

DISTINCT

在第八步中，会对 TV7 生成的记录进行去重操作，生成 VT8。事实上如果应用了 group by 子句那么 distinct 是多余的，原因同样在于，分组的时候是将列中唯一的值分成一组，同时只为每一组返回一行记录，那么所以的记录都将是不相同的。

ORDER BY

应用 order by 子句。按照 order_by_condition 排序 VT8，此时返回的一个游标，而不是虚拟表。sql 是基于集合的理论的，集合不会预先对他的行排序，它只是成员的逻辑集合，成员的顺序是无关紧要的。

SQL 语句执行的过程如下：

（6）简述触发器、函数、视图、存储过程？

触发器：使用触发器可以定制用户对表进行【增、删、改】操作时前后的行为,触发器无法由用户直接调用，而知由于对表的【增/删/改】操作被动引发的

函数：是MySQL数据库提供的内部函数(当然也可以自定义函数)。这些内部函数可以帮助用户更加方便-的处理表中的数据

视图：视图是虚拟表或逻辑表，它被定义为具有连接的SQL SELECT查询语句。

存储过程：存储过程是存储在数据库目录中的一坨的声明性SQL语句，数据库中的一个重要对象,有效提高了程序的性能

（7）听说过视图吗？那游标呢？

视图是一种虚拟的表，通常是有一个表或者多个表的行或列的子集，具有和物理表相同的功能游标是对查询出来的结果集作为一个单元来有效的处理。

一般不使用游标，但是需要逐条处理数据的时候，游标显得十分重要。

（8）视图的作用是什么？可以更改吗？

视图是虚拟的表，与包含数据的表不一样，视图只包含使用时动态检索数据的查询；不包含任何列或数据。

使用视图可以简化复杂的 sql 操作，隐藏具体的细节，保护数据；视图创建后，可以使用与表相同的方式利用它们。

视图不能被索引，也不能有关联的触发器或默认值，如果视图本身内有order by 则对视图再次order by将被覆盖。

创建视图：

create view xxx as xxxx

对于某些视图比如未使用联结子查询分组聚集函数Distinct Union等，是可以对其更新的，对视图的更新将对基表进行更新；但是视图主要用于简化检索，保护数据，并不用于更新，而且大部分视图都不可以更新。

五、表结构相关

（1）为什么要尽量设定一个主键?

主键是数据库确保数据行在整张表唯一性的保障,即使业务上本张表没有主键,也建议添加一个自增长的 ID 列作为主键.

设定了主键之后,在后续的删改查的时候可能更加快速以及确保操作数据范围安全。

（2）主键使用自增 ID 还是 UUID?

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

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

总之，在数据量大一些的情况下，用自增主键性能会好一些。

图片来源于《高性能MySQL》: 其中默认后缀为使用自增ID,_uuid为使用 UUID为主键的测试，测试了插入 100w 行和 300w 行的性能。

（3）字段为什么要求定义为not null?

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

（4）如果要存储用户的密码散列,应该使用什么字段进行存储?

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

（5）说一说Drop、Delete与Truncate的共同点和区别?

Drop直接删掉表;
Truncate删除表中数据，再插入时自增长id又从1开始 ;
Delete删除表中数据，可以加where字句。

（6）数据库中的主键、超键、候选键、外键是什么？

超键：在关系中能唯一标识元组的属性集称为关系模式的超键

候选键：不含有多余属性的超键称为候选键。也就是在候选键中，若再删除属性，就不是键了！

主键：用户选作元组标识的一个候选键程序主键

外键：如果关系模式R中属性K是其它模式的主键，那么k在模式R中称为外键。

六、其他问题

（1）MySQL 中的 varchar 和 char 有什么区别?

char 是一个定长字段，假如申请了char(10)的空间，那么无论实际存储多少内容。

该字段都占用 10 个字符，而 varchar 是变长的，也就是说申请的只是最大长度，占用的空间为实际字符长度 +1，最后一个字符存储使用了多长的空间

在检索效率上来讲，char > varchar，因此在使用中，如果确定某个字段的值的长度，可以使用 char，否则应该尽量使用 varchar。

例如存储用户 MD5 加密后的密码，则应该使用 char。

（2）varchar(10) 和 int(10) 代表什么含义?

varchar的10代表了申请的空间长度,也是可以存储的数据的最大长度,而int的10只是代表了展示的长度,不足10位以0填充.

也就是说,varchar(10) 和int(10)所能存储的数字大小以及占用的空间都是相同的,只是在展示时按照长度展示.

（3）MySQL的binlog有有几种录入格式?分别有什么区别?

有三种格式：statement、row 和 mixed.

statement 模式下,记录单元为语句.即每一个sql造成的影响会记录.由于sql的执行是有上下文的,因此在保存的时候需要保存相关的信息,同时还有一些使用了函数之类的语句无法被记录复制.

row 级别下,记录单元为每一行的改动,基本是可以全部记下来但是由于很多操作,会导致大量行的改动(比如alter table),因此这种模式的文件保存的信息太多,日志量太大.

mixed. 一种折中的方案,普通操作使用statement记录,当无法使用statement的时候使用row.

4）超大分页怎么处理?

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

数据库层面,这也是我们主要集中关注的(虽然收效没那么大),类似于

select * from table where age > 20 limit 1000000,10 这种查询其实也是有可以优化的余地的.

这条语句需要 load 1000000数据然后基本上全部丢弃,只取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泄漏且连续被人恶意攻击.

（5）说一说三个范式?

第一范式: 每个列都不可以再拆分。

第二范式: 非主键列完全依赖于主键，而不能是依赖于主键的一部分。

第三范式: 非主键列只依赖于主键，不依赖于其他非主键。

在设计数据库结构的时候，要尽量遵守三范式，如果不遵守，必须有足够的理由。

比如性能，事实上我们经常会为了性能而妥协数据库的设计。

（6）left join、right join 以及 inner join的区别?

left join：左关联，主表在左边，右边为从表。如果左侧的主表中没有关联字段，会用null 填满

right join：右关联主表在右边和letf join相反

inner join：内关联只会显示主表和从表相关联的字段，不会出现null

（7）什么是数据库约束,常见的约束有哪几种?

数据库约束用于保证数据库、表数据的完整性（正确性和一致性）。

可以通过定义约束\索引\触发器来保证数据的完整性。

总体来讲,约束可以分为:

主键约束：primary key；外键约束：foreign key；唯一约束：unique；检查约束：check；空值约束：not null；默认值约束：default；

（8）什么是sql注入？

SQL 注入攻击指的是通过构建特殊的输入作为参数传入Web应用程序，而这些输入大都是SQL语法里的一些组合，通过执行SQL语句进而执行攻击者所要的操作，其主要原因是程序没有细致地过滤用户输入的数据，致使非法数据侵入系统。

（9）简述数据库的读写分离？

读写分离为了确保数据库产品的稳数据定性，很多数据库拥有双机热备功能。

也就是，第一台数据库服务器，是对外提供增删改业务的生产服务器；第二台数据库服务器，主要进行读的操作。

（10）MySQL数据库cpu飙升的话，要怎么处理呢？

排查过程：

使用 top 命令观察，确定是 mysqld 导致还是其他原因。

如果是mysqld导致的，show processlist，查看session情况，确定是不是有消耗资源的sql在运行。

找出消耗高的 sql，看看执行计划是否准确，索引是否缺失，数据量是否太大。

处理：

kill 掉这些线程(同时观察 cpu 使用率是否下降)，

进行相应的调整(比如说加索引、改 sql、改内存参数)

重新跑这些 SQL。

（11）MYSQL的主从延迟，你怎么解决？

主从复制分了五个步骤进行：

主从复制

步骤一：主库的更新事件(update、insert、delete)被写到binlog

步骤二：从库发起连接，连接到主库。

步骤三：此时主库创建一个binlog dump thread，把binlog的内容发送到从库。

步骤四：从库启动之后，创建一个I/O线程，读取主库传过来的binlog内容并写入到relay log

步骤五：还会创建一个SQL线程，从relay log里面读取内容，从Exec_Master_Log_Pos位置开始执行读取到的更新事件，将更新内容写入到slave的db

主从同步延迟的原因：

一个服务器开放Ｎ个链接给客户端来连接的，这样有会有大并发的更新操作, 但是从服务器的里面读取binlog的线程仅有一个，当某个SQL在从服务器上执行的时间稍长或者由于某个SQL要进行锁表就会导致，主服务器的SQL大量积压，未被同步到从服务器里。

这就导致了主从不一致，也就是主从延迟。

主从同步延迟的解决办法：

主服务器要负责更新操作，对安全性的要求比从服务器要高，所以有些设置参数可以修改，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之类的设置等。

选择更好的硬件设备作为 slave。

把一台从服务器当度作为备份使用，而不提供查询，那边他的负载下来了，执行relay log 里面的SQL效率自然就高了。

增加从服务器，这个目的还是分散读的压力，从而降低服务器负载。

（12）如果让你做分库与分表的设计，简单说说你会怎么做？

分库分表方案:

水平分库：以字段为依据，按照一定策略（hash、range等），将一个库中的数据拆分到多个库中。

水平分表：以字段为依据，按照一定策略（hash、range等），将一个表中的数据拆分到多个表中。

垂直分库：以表为依据，按照业务归属不同，将不同的表拆分到不同的库中。

垂直分表：以字段为依据，按照字段的活跃性，将表中字段拆到不同的表（主表和扩展表）中。

常用的分库分表中间件：

sharding-jdbc

Mycat

分库分表可能遇到的问题：

事务问题：需要用分布式事务
跨节点Join的问题：解决这一问题可以分两次查询实现
跨节点的count,order by,group by以及聚合函数问题：分别在各个节点上得到结果后在应用程序端进行合并。
数据迁移，容量规划，扩容等问题
ID问题：数据库被切分后，不能再依赖数据库自身的主键生成机制，最简单可以考虑 UUID
跨分片的排序分页问题

（13）count(1)、count(*)与count(列名)的执行区别

执行效果上：

count(*)：包括了所有的列，相当于行数，在统计结果的时候，不会忽略列值为NULL

count(1)：包括了忽略所有列，用1代表代码行，在统计结果的时候，不会忽略列值为NULL

count(列名)：只包括列名那一列，在统计结果的时候，会忽略列值为空（这里的空不是只空字符串或者0，而是表示null）的计数，即某个字段值为NULL时，不统计。

执行效率上：

列名为主键，count(列名)会比count(1)快

列名不为主键，count(1)会比count(列名)快

如果表多个列并且没有主键，则 count（1）的执行效率优于 count（*）

如果有主键，则 select count（主键）的执行效率是最优的

如果表只有一个字段，则 select count（*）最优。

count(*) 与 count(1) 与 count(列名) 的差异

（14）sql 语句中where 1=1的作用

SQL注入

语法规范

拷贝表

复制表结构

1=1的坏处

（15）sql中null与空值的区别

1.占用空间区别：空值(‘‘)的长度是0，是不占用空间的；而的NULL长度是NULL，是占用空间的

2.插入/查询方式区别：NULL值查询使用is null/is not null查询，而空值(‘‘)可以使用=或者!=、<、>等算术运算符。

3.COUNT 和 IFNULL函数：使用 COUNT(字段) 统计会过滤掉 NULL 值，但是不会过滤掉空值。

4.索引字段说明：在有NULL值的字段上使用常用的索引，如普通索引、复合索引、全文索引等不会使索引失效。在官网查看在空间索引的情况下，说明了索引列必须为NOT NULL。

七、优化相关

（1）日常工作中你是怎么优化SQL的？

（1.1）表结构优化

尽量使用数字型字段

若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。

这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。

尽可能的使用 varchar 代替 char

变长字段存储空间小，可以节省存储空间。

当索引列大量重复数据时，可以把索引删除掉

比如有一列是性别，几乎只有男、女、未知，这样的索引是无效的。

（1.2）查询优化

应尽量避免在 where 子句中使用!=或<>操作符
应尽量避免在 where 子句中使用 or 来连接条件
任何查询也不要出现select *
避免在 where 子句中对字段进行 null 值判断

（1.3）索引优化

对作为查询条件和 order by的字段建立索引

避免建立过多的索引，多使用组合索引

（1.4）慢查询优化

分析语句，是否加载了不必要的字段/数据

分析 SQL 执行句话，是否命中索引等

如果 SQL 很复杂，优化 SQL 结构

如果表数据量太大，考虑分表

说说分库与分表的设计

分库分表方案，分库分表中间件，分库分表可能遇到的问题