MySQL知识点总结

1.简述数据库的三大范式

第一范式(原子性)：字段不可分。字段不可再分,否则就不是关系数据库

第二范式(唯一性)：一个表只说明一个事物，有主键且非主键依赖主键

第三范式：不存在传递依赖，非主键字段不能相互依赖

注：第二范式要遵循第一范式，第三范式要遵循第二范式

例子：

不满足1NF：姓名，年龄，住址。这里住址还能继续分为哪个市哪个县以及最后的详细住址

不满足2NF：姓名，年龄，课程名称，成绩，学分。这里学分与主键学生姓名无关而与课程有关，故可以继续拆分成学生表和课程表。

不满足3NF：姓名, 年龄, 所在学院, 学院地址。虽说一个学生只有一个学院地址但是学院和学院地址存在依赖关系，故可继续拆分成学生表和学院表。

2.简述MySQL的架构

MySQL可以分为应用层,逻辑层,数据库引擎层,物理层。

应用层： 负责响应客户端请求和客户端建立连接，返回数据。

逻辑层： 负责具体的查询操作，事务管理，存储管理，恢复管理以及其他的功能。包括SQK接口，解析器，优化器，Cache与buffer。

数据库引擎层： 有常见的MyISAM,InnoDB等等。

物理层： 实际物理磁盘(存储）上的数据库文件，如数据文件，日志文件。

3.简述执行SQL语言的过程

客户端首先通过连接器进行身份认证和权限相关的操作

如果是执行查询语句的时候，会先查询缓存，但MySQL 8.0 版本后该步骤移除。

没有命中缓存的话，SQL 语句就会经过解析器，分析语句，包括语法检查等等。

通过优化器，将用户的SQL语句按照 MySQL 认为最优的方案去执行。

执行语句，并从存储引擎返回数据。

4.简述MySQL的共享锁，排他锁，意向共享锁以及意向排他锁

共享锁（S锁）也称为读锁，相互不阻塞，多个客户在同一时刻可以同时读取同一个资源而不相互干扰。

排他锁（X锁）也称为写锁，会阻塞其他的写锁和读锁，确保在给定时间内只有一个用户能执行写入并防止其他用户读取正在写入的同一资源。

意向共享锁（IS锁）：事务在请求S锁前，要先获得IS锁

意向排他锁（IX锁）：事务在请求X锁前，要先获得IX锁

兼容情况：

• X 和所有锁都冲突
• IX 兼容 IX 和 IS
• S 兼容 S 和 IS
• IS 兼容 IS、IX 和 S

5.简述MySQL中按粒度的锁分类

表级锁： 对当前操作的整张表加锁，实现简单，加锁快，但并发能力低。

行锁： 锁住某一行，如果表存在索引，那么记录锁是锁在索引上的，如果表没有索引，那么 InnoDB 会创建一个隐藏的聚簇索引加锁。行级锁能大大减少数据库操作的冲突。其加锁粒度最小，并发度高，但加锁的开销也最大，加锁慢，会出现死锁。

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

Gap 锁： 也称为间隙锁: 锁定一个范围但不包括记录本身。其目的是为了防止同一事物的两次当前读出现幻读的情况。

Next-key Lock： 行锁+gap锁。

6.如何解决数据库死锁

在同一个事务中，尽可能做到一次锁定所需要的所有资源，减少死锁概率。

以固定的顺序访问表和行。即按顺序申请锁，这样就不会造成互相等待的场面。

当查询的时间达到锁等待超时的设定后放弃锁请求。

避免死锁的方式：

大事务拆小。大事务更倾向于死锁，如果业务允许，将大事务拆小。

为表添加合理的索引。如果不走索引将会为表的每一行记录添加上锁，死锁的概率大大增大。

7.简述乐观锁和悲观锁

乐观锁：对于数据冲突保持一种乐观态度，操作数据时不会对操作的数据进行加锁，只有到数据提交的

时候才通过CAS机制来验证数据是否存在冲突。

悲观锁：对于数据冲突保持一种悲观态度，在修改数据之前把数据锁住，然后再对数据进行读写，在它

释放锁之前任何人都不能对其数据进行操作，直到前面一个人把锁释放后下一个人数据加锁才可对数据

进行加锁，然后才可以对数据进行操作，一般数据库本身锁的机制都是基于悲观锁的机制实现的。

8.MySQL的存储引擎了解吗，介绍一下

比较常用的有InnoDB和MyISAM

MyISAM不支持事务，Myisam支持表级锁，不支持行级锁，表不支持外键，索引为非聚集索引，该存储引擎存有表的行数，count运算会更快。适合查询频繁，不适合对于增删改要求高的情况

InnoDB 是 MySQL 的默认事务型引擎，支持事务。支持表级锁和行级锁，支持外键，索引使用聚集索引，适合数据增删改查都频繁的情况

另外，InnoDB 采用 MVCC 来支持高并发，并且实现了四个标准的隔离级别。其默认级别是可重复度（REPEATABLEREAD），并通过间隙锁策略防止幻读，间隙锁使 InnoDB 不仅仅锁定查询涉及的行，还会对索引中的间隙进行锁定防止幻行的插入

Memory存储引擎将所有数据都保存在内存，不需要磁盘 IO。支持哈希索引，因此查找速度极快。Memory 表使用表级锁，因此并发写入的性能较低

如果内存出现异常会影响到数据的完整性。如果重启机器或者关机，表中的所有数据都将消失，因此，基于Memory存储引擎的表的生命周期都比较短，一般都是一次性的

9.索引是什么

索引是存储引擎中用于快速找到记录的一种数据结构。在关系型数据库中，索引具体是一种对数据库中一列或多列的值进行排序的存储结构

10.为什么引入索引

为了提高数据查询的效率。索引对数据库查询良好的性能非常关键，当表中数据量越来越大，索引对性能的影响越重要。

11.Mysql常见的索引有哪些

按照逻辑划分：

普通索引

唯一索引

主键索引

全文索引，搜索引擎关键技术，定义一个词库，然后在文章中查找每个词条(term)出现的频率和位置，把这样的频率和位置信息按照词库的顺序归纳，这样就相当于对文件建立了一个以词库为目录的索引，这样查找某个词的时候就能很快的定位到该词出现的位置。

12.简述B-Tree和B+树

B-Tree ：是一种自平衡的多叉树。每个节点都存储关键字值。其左子节点的关键字值小于该节点关键字值，且右子节点的关键字值大于或等于该节点关键字值。

特点：

• 所有键值分布在整个树中
• 任何关键字出现且只出现在一个节点中
• 搜索有可能在非叶子节点结束
• 在关键字全集内做一次查找，性能逼近二分查找算法

B+树也是是一种自平衡的多叉树。其基本定义与B树相同

特点：

所有关键字存储在叶子节点，非叶子节点不存储真正的data
为所有叶子节点增加了一个链指针，叶子节点形成有序链表，范围查询方便
层级更低，IO 次数更少
每次都需要查询到叶子节点，查询性能稳定

13.简述Hash索引

哈希索引对于每一行数据计算一个哈希码，并将所有的哈希码存储在索引中，同时在哈希表中保存指向每个数据行的指针。

只有 Memory 引擎显式支持哈希索引。

Hash索引不支持范围查询，无法用于排序，也不支持部分索引列匹配查找。

14.简述自适应Hash索引

InnoDB对于频繁使用的某些索引值，会在内存中基于B+Tree索引之上再创键一个哈希索引，这也被称为自适应Hash索引。

15.简述聚集索引 非聚集索引 稀疏索引 稠密索引

聚集索引：聚簇索引是一种数据存储方式，把数据存在节点中，查询效率高。

**非聚集索引：**每个索引键值都对应有一个索引项

**稠密索引：**每个索引键值都对应有一个索引项

稠密索引能够比稀疏索引更快的定位一条记录。

**稀疏索引：**相对于稠密索引，一个索引项下包含多条数据记录；在搜索时，找到其最大的不小于当前查找数据的最大索引记录，然后从该记录开始向后顺序查询直到找到为止。

稀疏索引所占空间更小，且插入和删除时的维护开销也小。

16.简述辅助索引和回表查询

辅助索引是非聚集索引，叶子节点不包含记录的全部数据，只存储主键值，然后又通过主键值到聚集索引中进行回表查询。

17.简述联合索引和最左匹配原则

联合索引是指两个或两个以上的字段共同构成一个索引。

在MySQL建立联合索引时会遵守最左前缀匹配原则，即最左优先，在检索数据时从联合索引的最左边开始匹配。对于联合索引的查询，如果精确匹配联合索引的左边连续一列或者多列，则mysql会一直向右匹配直到遇到范围查询（>,<,between,like）就停止匹配。Mysql会对第一个索引字段数据进行排序，在第一个字段基础上，再对第二个字段排序。

详解参考：MYSQL | 最左匹配原则的原理 - 腾讯云开发者社区-腾讯云

18.简述覆盖索引

一个索引包含了（或覆盖了）所有满足查询结果的数据就叫做覆盖索引。

19.为什么数据库不用红黑树用B+树

红黑树的出度为 2，而 B Tree 的出度一般都非常大。红黑树的树高 h 很明显比 B Tree 大非常多，IO次数很多，导致会比较慢，因此检索的次数也就更多。

B+Tree 相比于 B-Tree 更适合外存索引，拥有更大的出度，IO次数较少，检索效率会更高。

20.使用聚集索引，基于主键索引的查询和非主键索引的查询有什么区别？

基于主键的普通查询仅查找主键这棵树，基于非主键的查询有可能存在回表过程。

21.非主键索引的查询一定会回表吗？

不一定，只需要在一棵索引树上就能获取SQL查询所需的所有列数据，无需回表，速度更快。如select 主键 from 非主键=XX，此时非主键索引叶子节点即可拿到主键信息，不用回表。

22.索引的设计原则

1. 为经常查询的列设计索引，最适合索引的列是在where后面出现的列或者连接句子中指定的列，而不是出现在SELECT关键字后面的选择列表中的列。
2. 为需要经常排序和分组的列建立索引。
3. 频繁增删改的字段不要建立索引
4. 索引列的基数越大，索引效果越好，即区分度越高，索引的效果越好。
5. 尽量使用短索引，对于较长的字符串使用索引时应指定一个较短的前缀长度，因为较小的索引涉及到的磁盘I/O较少，并且索引高速缓存中的块可以容纳更多的键值，会使得查询速度更快。
6. 尽量利用最左匹配原则建立联合索引
7. 不要过度索引，每个索引都需要额外的物理空间，维护也需要花费时间，所以索引不是越多越好。

23.索引失效的场景

1. 不遵循最左前缀原则
2. 使用模糊查询的时候以%开头也会导致索引失效
3. 索引列如果使用了隐式转换也会导致索引失效
4. 使用or查询的部分字段没有索引
5. 索引列不独立. 独立是指: 列不能是表达式的一部分, 也不能是函数的参数

24.简述MySQL使用EXPLAIN 的关键字段

explain关键字用于分析sql语句的执行情况，可以通过他进行sql语句的性能分析。

type：表示连接类型，从好到差的类型排序为

• system：系统表，数据已经加载到内存里。
• const：常量连接，通过索引一次就找到。
• eq_ref：唯一性索引扫描，返回所有匹配某个单独值的行。
• ref：非主键非唯一索引等值扫描，const或eq_ref改为普通非唯一索引。
• range：范围扫描，在索引上扫码特定范围内的值。
• index：索引树扫描，扫描索引上的全部数据。
• all：全表扫描。

key：显示MySQL实际决定使用的键。

key_len：显示MySQL决定使用的键长度，长度越短越好

Extra：额外信息

• Using filesort：MySQL使用外部的索引排序，很慢需要优化。
• Using temporary：使用了临时表保存中间结果，很慢需要优化。
• Using index：使用了覆盖索引。
• Using where：使用了where。

25.简述MySQL优化流程

通过慢日志定位执行较慢的SQL语句

利用explain对这些关键字段进行分析

根据分析结果进行优化

26.简述MySQL中的日志log

主要包括：重做日志（redo log）、回滚日志（undo log）、二进制日志（binlog）、错误日志（errorlog）、慢查询日志（slow query log）、一般查询日志（general log）、中继日志（relay log）。

其中redo log，undo log和binlog是与MySQL事务有关的日志

redo log是InnoDB存储引擎层的日志，属于物理日志，在一条更新语句执行的时候InnoDB引擎就把更新的策略记录在redo log中，并采用先写日志再写磁盘的方式，这样在数据库发生异常，在下次重启数据库的时候就可以把之前的操作恢复。

binlog是属于MySQL Server层面的，又称为归档日志，属于逻辑日志，是以二进制的形式记录的是这个语句的原始逻辑。没有crash-safe能力。

undo是InnoDB存储引擎层的日志，该log保存了事务发生之前的数据的一个版本，用来回滚行记录到某个版本。undo log一般是逻辑日志，根据每行记录进行记录。redo log保证持久性，undo log保证原子性。

errorlog：记录着mysqld启动和停止,以及服务器在运行过程中发生的错误的相关信息。在默认情况下，系统记录错误日志的功能是关闭的，错误信息被输出到标准错误输出。

slow query log：慢日志记录执行时间过长和没有使用索引的查询语句

general log：记录了服务器接收到的每一个查询或是命令，无论这些查询或是命令是否正确甚至是否包含语法错误，general log 都会将其记录下来 ，记录的格式为 {Time ，Id ，Command，Argument }。

relay log：从服务器I/O线程将主服务器的binlog读取过来记录到从服务器本地文件，然后从服务器SQL线程会读取relay log日志的内容并应用到从服务器，从而使从服务器和主服务器的数据保持一致

27.为什么bin log不具有crash-safe的能力？

crash-safe：保证即使数据库发生异常重启，之前提交的记录都不会丢失的能力

• InnoDB就是因为MySQL的binlog没有崩溃恢复的能力才引入其原有的redo log的。
• binlog没有记录数据页修改的详细信息，不具备恢复数据页的能力，只记录数据行的增删改。当一个事务做插入/更新/删除时，其实涉及到的数据页改动非常细致和复杂，包括行的字段改动以及行头部以及数据页头部的改动，甚至b+tree会因为插入一行而发生若干次页面分裂，那么事务也会把所有这些改动记录下来到redolog中。

28.redo log与binlog的区别？

redo log是InnoDB引擎特有的，只记录该引擎中表的修改记录。binlog是MySQL的Server层实现的，会记录所有引擎对数据库的修改。

redo log是物理日志，记录的是在具体某个数据页上做了什么修改；binlog是逻辑日志，记录的是这个语句的原始逻辑。

redo log是循环写的，空间固定会用完；binlog是可以追加写入的，binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

29.两阶段提交是什么？

目的：

为了保证binlog和redo log两份日志的逻辑一致，最终保证恢复到主备数据库的数据是一致的

具体流程：

• 执行器调用存储引擎接口，存储引擎将修改更新到内存中后，将修改操作记录redo log中，此时redo log处于prepare状态。

• 存储引擎告知执行器执行完毕，执行器生成这个操作对应的binlog，并把bin log写入磁盘。

• 执行器调用引擎的提交事务接口，引擎把刚刚写入的redo log改成提交commit状态，更新完成。

30.简述事务

事务要求保证事务内的语句要么全部执行成功，要么全部执行失败。

事务具有四大特性

原子性：一个事务中的所有操作要么全部完成，要么全部不完成。

一致性：事务执行前后数据库的状态保存一致，数据库中元素有加必有减保持守恒一致。

隔离性：多个并发事务对数据库进行操作，事务间互不干扰。

持久性：事务执行完毕，对数据的修改是永久的，即使系统故障也不会丢失

31.数据库中多个事务同时进行可能会出现什么问题？

丢失修改： 两个事务在并发下同时进行更新，后一个事务的更新覆盖了前一个事务更新的情况。未保证一致性。

脏读： 当前事务可以查看到别的事务未提交的数据。

不可重读： 在同一事务中，使用相同的查询语句，同一数据资源莫名改变了。

幻读： 在同一事务中，使用相同的查询语句，莫名多出了一些之前不存在的数据，或莫名少了一些原先存在的数据。

32.SQL事务的隔离级别有哪些？

读未提交： 一个事务还没提交，它做的变更就能被别的事务看到。

读已提交： 一个事务提交后，它做的变更才能被别的事务看到。

可重复读： 一个事务执行过程中看到的数据总是和事务启动时看到的数据是一致的。在这个级别下事务未提交，做出的变更其它事务也看不到。

串行化： 对于同一行记录进行读写会分别加读写锁，当发生读写锁冲突，后面执行的事务需等前面执行的事务完成才能继续执行。

33.什么是MVCC

MVCC为多版本并发控制，即同一条记录在系统中存在多个版本。

其存在目的是在保证数据一致性的前提下提供一种高并发的访问性能。对数据读写在不加读写锁的情况下实现互不干扰,从而实现数据库的隔离性,在事务隔离级别为读提交和可重复读中使用到。

在InnoDB中，事务在开始前会向事务系统申请一个事务ID，该ID是按申请顺序严格递增的。每行数据具有多个版本，每次事务更新数据都会生成新的数据版本，而不会直接覆盖旧的数据版本。数据的行结构中包含多个信息字段。其中实现MVCC的主要涉及最近更改该行数据的事务ID（DB_TRX_ID）和可以找到历史数据版本的指针（DB_ROLL_PTR）。InnoDB在每个事务开启瞬间会为其构造一个记录当前已经开启但未提交的事务ID的视图数组。通过比较链表中的事务ID与该行数据的值与对应的DB_TRX_ID，并通过DB_ROLL_PTR找到历史数据的值以及对应的DB_TRX_ID来决定当前版本的数据是否应该被当前事务所见。最终实现在不加锁的情况下保证数据的一致性。

34.读提交和可重复读都基于MVCC实现，有什么区别？

可重复读级别下，只会在事务开始前创建视图，事务中后续的查询共用一个视图。

读提交级别下每个语句执行前都会创建新的视图。因此对于可重复读，查询只能看到事务创建前就已经提交的数据。而对于读提交，查询能看到每个语句启动前已经提交的数据。

35.InnoDB如何保证事务的原子性、持久性和一致性？

利用undo log保障原子性。该log保存了事务发生之前的数据的一个版本，可以用于回滚，从而保证事务原子性。

利用redo log保证事务的持久性，该log关注于事务的恢复.在重启mysql服务的时候，根据redo log进行重做，从而使事务有持久性。

利用undo log+redo log保障一致性。事务中的执行需要redo log，如果执行失败，需要undo log 回滚。

36.MySQL是如何保证主备的一致性的？

MySQL通过binlog（二进制日志）实现主备一致。binlog记录了所有修改了数据库或可能修改数据库的语句，而不会记录select、show这种不会修改数据库的语句。在备份的过程中，主库A会有一个专门的线程将主库A的binlog发送给备库B进行备份。

其中binlog有三种记录格式：

statement: 记录对数据库进行修改的语句本身，有可能会记录一些额外的相关信息。优点是binlog日志量少，IO压力小，性能较高。缺点是由于记录的信息相对较少，在不同库执行时由于上下文的环境不同可能导致主备不一致，可靠性不高。

row: 记录对数据库做出修改的语句所影响到的数据行以及对这些行的修改。比如当修改涉及多行数据，会把涉及的每行数据都记录到binlog。优点是能够完全的还原或者复制日志被记录时的操作，可靠性高。缺点是日志量占用空间较大，IO压力大，性能消耗较大。

mixed：混合使用上述两种模式，一般的语句用statement，特殊函数用row进行记录。MySQL会自己判断这条语句是否会造成主备不一致，如果有可能则用row。

37.WAL技术是什么？

WAL的全称是Write-Ahead Logging，它的关键点就是先写日志，再写磁盘。事务在提交写入磁盘前，会先写到redo log里面去。

如果直接写入磁盘涉及磁盘的随机I/O访问，涉及磁盘随机I/O访问是非常消耗时间的一个过程，相比之下先写入redo log，后面再找合适的时机批量刷盘能提升性能。

38.简述MySQL主从复制

MySQL提供主从复制功能将主库中的数据复制到从数据库中，可以方便的实现数据的多处自动备份，不仅能增加数据库的安全性，还能进行读写分离，提升数据库负载性能。

基本实现流程是将主库的操作写入binlog二进制日志文件，将二进制日志文件binlog传递到从库，在从库中重放binlog中的操作过程，从而达到对主库的操作（增删改）同步更新至从库的目的。

读写分离：即只在MySQL主库上写，只在MySQL从库上读，以减少数据库压力，提高性能。

39.MySQL如何保证主从一致性

早期版本：异步复制。主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，如果主机crash掉了，但是主机上的binlog还没有传递到从库就会造成主从不一致的情况。

MySQL 5.5之后：半同步复制。主库在应答客户端提交的事务前需要保证至少一个从库接收并写到relay log中

MySQL主从模式的数据一致性 - 简书 (jianshu.com)

40.MySQL数据存储过程

存储过程（Stored Procedure）是一种在数据库中存储复杂程序，以便外部程序调用的一种数据库对象。

存储过程是事先经过编译并存储在数据库中的一段为了完成特定功能的SQL语句的集合，用户可通过指定存储过程的名字并给定参数(需要时)来调用执行。

存储过程思想上很简单，就是数据库 SQL 语言层面的代码封装与重用。

41.MySQL数据库触发器

触发器简单来说就是监视某种情况，并触发某种操作。 当触发器所在表上出现指定事件(insert/update/delete)时，可指定时间(after/before)执行特定事件(insert/update/delete)。

42.SQL优化方法

核心就是避免全表扫描，多走索引。列举常用的一些优化方法：

1. 尽量对利用字段较多的建立索引，即在 where 及 order by 涉及的列上建立索引。
2. 尽量避免在 where 子句中使用 or ，null值判断，in 和对字段进行表达式操作
3. 建立索引时需要多考虑最左匹配原则

43.mysql的操作 增删改查SQL语句

增：INSERT INTO 表名（字段名1，字段名2，…）VALUES（值1，值2，…）

删：DELETE FROM 表名 [WHERE 条件表达式]/ truncate [TABLE ] 表名（删除整张表数据）

改：UPDATE 表名 SET 字段名1=值1，[ ，字段名2=值2，…] [ WHERE 条件表达式 ]

查：SELECT 字段名1，字段名2，… FROM 表名 [ WHERE 条件表达式 ]

44.drop、truncate和delete的区别

1. 在速度上，一般来说，drop> truncate > delete。
2. 在使用drop和truncate时一定要注意，虽然可以恢复，但为了减少麻烦，还是要慎重。
3. TRUNCATE 只能对TABLE； DELETE可以是table和view。
4. TRUNCATE 和DELETE只删除数据， DROP则删除整个表（结构和数据）
5. 如果想删除部分数据用delete，注意带上where子句，回滚段要足够大。
6. 如果想保留表而将所有数据删除，如果和事务无关，用truncate即可；如果和事务有关，或者想触发trigger，还是用delete；
7. 如果是整理表内部的碎片，可以用truncate跟上reuse stroage，再重新导入/插入数据。

45.什么情况下分表合适

针对存储了百万级乃至千万级条记录的大表。数据库在查询和插入的时候耗时太长，可通过分表，将大表拆分成小表，提升数据库性能。

46.关系型数据库与非关系型数据库区别

关系型数据库采用了关系模型（可以简单理解为二维表格类型）组织数据，一般可以遵守事务的ACID特性

不是由关系模型进行存储的均可视作非关系型数据库，比如以键值对的redis，图数据库等。

mysql是关系型数据库，主要用于存放持久化数据，将数据存储在硬盘中，读取速度较慢。性能低可靠性高

redis是非关系型数据库，也是缓存数据库，即将数据存储在缓存中，缓存的读取速度快，能够大大的提高运行效率，但是保存时间有限。性能高可靠性不高

47.mysql为什么要用自增id作为主键

直接原因是其存储机制。MySQL采用数据页进行数据存储。 如果采用自增主键，在原先数据页写满的情况下，MySQL对于新数据，直接开辟新页进行写操作。 如果不采用自增主键，为保障索引有序，新数据需插入到合适位置上，由此针对页数据满的情况下，MySQL需要申请新页，并将一部分之前的页数据挪到新页上，保证按索引有序存储，相对自增主键IO开销更大。

48.大数据量的分页查询怎么优化

可以使用索引并利用偏移量

select * from table where num = 8 limit 100000,100;

变为

select * from table where num = 8 and id >= (
    select id from table where num = 8 limit 100000,1
) limit 100;

由于id走了索引，因此速度会有一定提升。

49.char和varchar区别

char的长度是不可变的，而varchar的长度是可变的。 因此char效率高，varchar效率偏低。

50.主键和唯一索引的区别的是什么

1. 主键是一种约束，唯一索引是一种索引
2. 主键创建后一定包含一个唯一性索引，唯一性索引并不一定就是主键。
3. 唯一性索引列允许空值，而主键列不允许为空值
4. 主键可以被其他表引用为外键，而唯一索引不能。
5. 一张表只能有一个主键索引但不能有多个唯一索引

51.InnoDB可重复读是否存在幻读问题

不存在，InnoDB通过引入间隙锁+行锁（next key lock）的方式，解决了幻读问题。

52.分库分表怎么做

分表：

垂直分表：表中的字段较多，一般将不常用的、 数据较大、长度较长的拆分到“扩展表“。一般情况加表的字段可能有几百列，此时是按照字段进行数竖直切。注意垂直分是列多的情况。

水平分区：单表的数据量太大。按照某种规则（RANGE,HASH取模等），切分到多张表里面去。 但是这些表还是在同一个库中，所以库级别的数据库操作还是有IO瓶颈。这种情况是不建议使用的，因为数据量是逐渐增加的，当数据量增加到一定的程度还需要再进行切分。比较麻烦。

分库：

垂直分库：一个数据库的表太多。此时就会按照一定业务逻辑进行垂直切，比如用户相关的表放在一个数据库里，订单相关的表放在一个数据库里。注意此时不同的数据库应该存放在不同的服务器上，此时磁盘空间、内存、TPS等等都会得到解决。

水平分表：水平分库理论上切分起来是比较麻烦的，它是指将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表，只是表中数据集合不同。 水平分库分表能够有效的缓解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件资源等的瓶颈。

三分钟理解分库分表 - 知乎 (zhihu.com)

本文章大部分题目来源于公众号“后端小牛说中”，如有错误欢迎大家指正