【备战春招】总结几十场秋招面经，MySQL高频题TOP11

1. 为什么MySQL数据库使用B+树不使用B树？

MySQL数据库使用B+树而不是B树的主要原因有以下几点：

磁盘IO优化：B+树在内部节点只存储索引键，而不存储数据记录，数据记录只存在于叶子节点。这样可以使得每个节点能够存储更多的索引键，减少树的高度，从而减少磁盘IO次数，提高查询效率。
范围查询效率高：由于B+树的所有叶子节点都通过指针连接在一起，形成一个有序链表，因此范围查询非常高效。而B树则需要在叶子节点和内部节点之间进行跳跃，效率相对较低。
更好的顺序访问性能：B+树的叶子节点形成有序链表，可以方便地进行顺序访问，适合于范围查询、排序等操作。而B树的叶子节点并没有连接在一起，需要通过中序遍历等方式才能实现有序访问。
更适合大规模数据存储：B+树的内部节点只存储索引键，相比于B树，可以存储更多的索引键，减少树的高度，适合于大规模数据存储。

MySQL选择使用B+树作为索引结构，主要是为了优化磁盘IO、提高范围查询效率、提升顺序访问性能和适应大规模数据存储的需求。

2. 唯一和主键索引的区别，唯一与主与聚簇、非聚簇的关系？

唯一索引和主键索引的区别在于约束性和可空性：

唯一索引：唯一索引是用来保证某一列或多列的取值在整个表中是唯一的。它可以包含空值，但是对于非空值，每个索引键值只能在表中出现一次。一个表可以有多个唯一索引。
主键索引：主键索引是一种特殊的唯一索引，用来唯一标识表中的每一行数据。主键索引要求索引键值不能为空，且在整个表中必须唯一。一个表只能有一个主键索引。

唯一索引和主键索引都可以用来提高查询效率，避免数据重复。它们的区别在于主键索引是对表中的数据行进行唯一标识，而唯一索引只是保证索引键值的唯一性。

关于聚簇索引和非聚簇索引，它们与唯一索引和主键索引的关系如下：

聚簇索引：聚簇索引是一种特殊的索引结构，它决定了数据在磁盘上的物理存储顺序。在聚簇索引中，数据行按照索引键的顺序进行存储。一个表只能有一个聚簇索引，通常是主键索引。
非聚簇索引：非聚簇索引是指除了聚簇索引以外的其他索引。在非聚簇索引中，索引键和数据行的存储顺序是分离的，索引键指向对应的数据行。一个表可以有多个非聚簇索引，包括唯一索引和非唯一索引。

唯一索引和主键索引是用来保证数据的唯一性，主键索引是一种特殊的唯一索引。聚簇索引和非聚簇索引是索引的物理存储方式，聚簇索引通常是主键索引，而非聚簇索引可以是唯一索引或非唯一索引。

3. 事务的特性有哪些？分别是怎么保证的？MySQL的默认隔离级别是什么？

事务具有以下四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）。

原子性（Atomicity）：事务是一个不可分割的工作单位，要么全部执行成功，要么全部回滚到初始状态。原子性通过日志和回滚操作来保证，如果事务执行失败，系统可以回滚到事务开始前的状态。
一致性（Consistency）：事务执行前后，数据库的完整性约束没有被破坏。一致性通过在事务提交前进行数据校验和约束检查来保证。
隔离性（Isolation）：多个事务并发执行时，每个事务都应该感觉不到其他事务的存在，每个事务都认为自己是唯一在执行的。隔离性通过锁机制和并发控制来保证，防止事务之间的相互干扰和数据不一致。
持久性（Durability）：一旦事务提交成功，其所做的修改将永久保存在数据库中，即使系统发生故障也不会丢失。持久性通过将事务的操作记录在日志中，并定期将日志写入磁盘来保证。

MySQL的默认隔离级别是可重复读（REPEATABLE READ）。在可重复读隔离级别下，事务会对查询的数据加锁，保证在事务执行期间，其他事务无法修改被查询的数据。这样可以避免脏读、不可重复读和幻读的问题。但是在可重复读隔离级别下，会导致并发性能较差，因为锁的粒度较大，会造成锁竞争的情况。可以根据实际需求选择合适的隔离级别，如读未提交（READ UNCOMMITTED）、读已提交（READ COMMITTED）或串行化（SERIALIZABLE）。

4. 请简述常用的索引有哪些种类?

B树索引：B树索引是一种平衡树结构，适用于范围查询和精确查找。它将数据按照索引键值的顺序存储在树中，可以快速定位到目标数据。
B+树索引：B+树索引是在B树索引的基础上进行了优化，将数据记录只存储在叶子节点，内部节点只存储索引键值。B+树索引适用于范围查询、排序和顺序访问等操作，常用于数据库系统中。
哈希索引：哈希索引使用哈希函数将索引键值映射到一个哈希桶中，可以快速定位到目标数据。哈希索引适用于等值查询，但不适用于范围查询和排序操作。
全文索引：全文索引用于对文本内容进行搜索，可以实现关键词的模糊匹配和语义搜索。全文索引常用于搜索引擎和文本处理系统中。
空间索引：空间索引用于对具有空间属性的数据进行查询，如地理位置信息、地图数据等。空间索引可以支持空间范围查询和空间关系查询。
唯一索引：唯一索引用于保证某一列或多列的取值在整个表中是唯一的。它可以用于快速查找和避免数据重复。
主键索引：主键索引是一种特殊的唯一索引，用于唯一标识表中的每一行数据。主键索引要求索引键值不能为空，且在整个表中必须唯一。

这些索引种类各有特点，根据实际需求和数据特点选择合适的索引类型可以提高查询效率和数据的一致性。

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

联合索引（Composite Index）是指在多个列上创建的索引，也称为复合索引或多列索引。它可以在一个索引中包含多个列的值，用于加快多列条件查询的速度。

需要注意联合索引中的顺序的原因如下：

查询条件的顺序：联合索引的顺序决定了查询条件的顺序。当查询中的条件与联合索引的列顺序一致时，可以最大程度地利用索引进行查询优化。如果查询条件与索引列的顺序不一致，可能无法充分利用索引，导致性能下降。
查询覆盖：联合索引可以覆盖多个查询条件，只需要扫描索引而不需要回表查询数据。但是，只有当查询条件按照索引列的顺序出现时，才能实现完全的查询覆盖。如果查询条件的顺序与索引列的顺序不一致，可能需要进行额外的回表查询，影响性能。
索引大小：联合索引的大小取决于索引列的数量和数据类型。通常情况下，索引的大小越小，查询的速度越快。因此，将最常用的列放在联合索引的前面可以减小索引的大小，提高查询性能。

联合索引中的顺序非常重要。正确选择联合索引的列顺序可以最大程度地提高查询性能，减少回表查询和索引大小，从而提高数据库的整体性能。

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

在建立索引时，需要考虑以下几个因素：

查询频率：需要考虑哪些列经常被用于查询条件，以及查询的频率。对于经常被使用的列，建立索引可以提高查询性能。
数据的唯一性：如果某一列的取值在整个表中是唯一的，可以考虑将其作为主键索引或唯一索引。
数据的分布：需要考虑数据在列中的分布情况。如果某一列的取值分布不均匀，建立索引可能不会带来明显的性能提升。
索引的大小：索引会占用存储空间，需要考虑索引的大小对数据库性能的影响。过大的索引可能会导致磁盘IO增加，过小的索引可能无法满足查询需求。
更新频率：需要考虑表中数据的更新频率。频繁更新的列可能会导致索引的维护成本增加，影响性能。
查询的覆盖度：需要考虑索引是否能够覆盖查询所需的列。如果索引能够满足查询的需求，可以减少回表查询，提高性能。
系统资源：建立索引会占用系统资源，包括内存和CPU。需要考虑系统的资源限制，避免过多的索引导致资源不足。
综合性能：需要综合考虑以上因素，选择合适的索引策略。有时候需要进行性能测试和优化，根据实际情况进行调整。

选择合适的索引策略可以提高数据库的查询性能和整体性能。不同的应用场景和数据特点可能需要不同的索引策略，需要根据实际情况进行权衡和选择。

7. 主键使用自增ID还是UUID?

选择主键使用自增ID还是UUID，取决于具体的应用场景和需求。下面是对两种主键选择的一些考虑：

自增ID：

优点：
- 简单易用：自增ID是数据库内置的机制，使用方便。
- 效率高：自增ID是按照顺序递增的，可以减少索引的碎片化，提高查询性能。
- 索引效率高：自增ID可以作为聚集索引，支持范围查询和排序操作。
缺点：
- 可预测性：自增ID的生成规则是递增的，可能会暴露数据的增长趋势，存在一定的安全风险。
- 分布式环境下的冲突：在分布式环境中，多个节点生成自增ID可能会出现冲突，需要额外的处理机制。

UUID：

优点：
- 唯一性：UUID是全局唯一标识符，几乎可以保证每个生成的ID都是唯一的。
- 安全性：UUID不容易被猜测，可以提高数据的安全性。
- 分布式环境下的适用性：UUID可以在分布式环境中生成，不会出现冲突。
缺点：
- 占用空间大：UUID是128位的，相比自增ID占用更多的存储空间。
- 索引效率低：UUID的无序性导致索引的碎片化，可能影响查询性能。
- 不适合作为聚集索引：UUID的无序性不适合作为聚集索引，不支持范围查询和排序操作。

如果需要简单易用、高效率的主键，可以选择自增ID。如果需要全局唯一性、安全性和适用于分布式环境，可以选择UUID。在实际应用中，也可以根据具体需求和权衡选择其他的主键生成策略。

8. 说一说innodb 的 MVCC机制？

InnoDB是MySQL中一种常用的存储引擎，它使用了MVCC（Multi-Version Concurrency Control）机制来实现并发控制和事务隔离。

InnoDB的MVCC机制主要包括以下几个关键点：

版本号：每个数据行都会有一个版本号，用于标识该数据行的创建时间或修改时间。
Read View：每个事务在开始时会创建一个Read View，用于确定事务开始时的数据库快照。Read View包含了事务开始时已提交的所有数据行的版本号。
快照读：在执行SELECT语句时，InnoDB会根据事务的Read View来确定可见的数据行。只有那些版本号早于或等于事务的Read View的数据行才会被读取，保证了读取的一致性。
Undo日志：当一个事务更新或删除数据时，InnoDB会将旧版本的数据行保存在Undo日志中。这样，其他事务在读取该数据行时可以通过Undo日志来获取旧版本的数据。
并发控制：InnoDB使用多版本并发控制来处理并发事务。不同事务之间的读写操作可以并发进行，互不干扰。读操作不会阻塞其他读操作，读操作也不会被写操作阻塞。只有读写操作之间存在冲突时，才会进行锁定。

通过MVCC机制，InnoDB实现了较好的并发性能和事务隔离性。读操作可以并发进行，不会被锁定，提高了并发性能。同时，通过版本号和Read View的控制，保证了读取的一致性和事务的隔离性。

需要注意的是，MVCC机制也会带来一些额外的开销，如存储空间的增加和Undo日志的维护。因此，在使用InnoDB时，需要根据具体的应用场景和需求进行权衡和选择。

9. 请解释一下数据库的锁机制。

数据库的锁机制是用于控制并发访问数据库的一种机制，它可以确保多个事务之间的数据操作不会相互干扰或产生冲突。常见的数据库锁包括共享锁（Shared Lock）和排他锁（Exclusive Lock）。

共享锁（Shared Lock）：
- 共享锁也称为读锁，它允许多个事务同时读取同一数据，但不允许其他事务对该数据进行修改。
- 共享锁之间是兼容的，即多个事务可以同时持有共享锁，不会相互阻塞。
- 共享锁的目的是保证读操作的一致性，多个事务可以同时读取数据，不会读到其他事务正在修改的数据。
排他锁（Exclusive Lock）：
- 排他锁也称为写锁，它在事务对数据进行修改时使用，确保其他事务无法同时读取或修改该数据。
- 排他锁之间是互斥的，即一个事务持有排他锁时，其他事务无法同时持有共享锁或排他锁。
- 排他锁的目的是保证写操作的原子性和一致性，确保在修改数据时不会被其他事务读取或修改。

数据库锁机制的使用需要根据具体的业务需求和事务操作进行合理的选择和管理。过多的锁可能会导致性能下降和死锁的发生，因此需要在保证数据一致性的前提下，尽量减少锁的使用和持有时间。

除了共享锁和排他锁，还有其他类型的锁，如意向锁、行级锁、表级锁等，不同的数据库管理系统可能会有不同的锁机制和实现方式。在实际应用中，需要根据具体的场景和需求选择合适的锁机制来保证数据的一致性和并发性能。