【京东】JDS 后端面经，面试体验很棒|0316

1. 来说说 MySQL的索引?

解析：

MySQL 索引属于必考题，难度中等。

参考回答：

一、MySQL索引原理

MySQL索引采用了B+树的数据结构，能够大大提高查询效率。它类似于书籍的目录，通过索引，数据库系统可以迅速定位到表中的特定数据，无需扫描整个表。

二、MySQL索引的优点

1. 提高查询速度：通过索引，数据库可以迅速找到所需数据，避免了全表扫描的耗时操作。
2. 保证数据的唯一性：通过唯一索引，可以确保数据库表中每一行数据的某列或多列组合是唯一的。
3. 加速表与表之间的连接：在执行连接操作时，如果连接的字段已经被索引，那么连接的速度会更快。

三、MySQL索引的缺点

1. 占用磁盘空间：索引本身需要占用一定的磁盘空间。
2. 降低写操作的性能：每次对表中的数据进行增、删、改操作时，索引也需要进行相应的调整，这可能会降低写操作的性能。

四、MySQL索引的使用场景

1. 经常需要搜索的列：对于经常出现在WHERE子句中的列，应该考虑建立索引。
2. 作为连接键的列：如果某列经常出现在连接（JOIN）操作中，也应该考虑建立索引。
3. 经常需要排序的列：如果某列经常需要按照其值进行排序，也可以考虑建立索引。

五、注意事项

1. 避免过度索引：不是每个列都需要建立索引，过多的索引会占用更多的磁盘空间，并可能降低写操作的性能。因此，需要根据实际情况进行选择。
2. 定期维护索引：随着时间的推移，数据库中的数据会发生变化，索引的性能也可能会受到影响。因此，需要定期检查和优化索引。

总的来说，MySQL索引是提高数据库查询性能的重要工具，但也需要根据实际情况进行合理使用和维护。

学习指引：MySQL索引详解（一文搞懂）

面经专栏直通车

面经专栏下载

2. MySQL索引为什么不用红黑树，AVL树，为什么要用 B+树?

解析：

MySQL 索引属于必考题，难度中等。

参考回答：

MySQL索引选择使用B+树而不是红黑树或AVL树，主要是基于B+树在数据库环境中的特定优势和特性。

1. 多路搜索特性：B+树是一个多路平衡搜索树，这意味着每个节点可以有多于两个的子节点。这种特性使得B+树相对于二叉树（如红黑树和AVL树）在树的高度上具有优势。在数据库中，树的高度直接关系到查询性能，因为每次查询都需要从根节点遍历到叶子节点。多路搜索特性有助于降低树的高度，从而减少I/O操作和查询时间。
2. 范围查询和排序性能：B+树特别适用于范围查询和排序操作。由于其叶子节点之间通过指针相连，可以很方便地遍历叶子节点以获取范围内的数据。相比之下，红黑树和AVL树在进行范围查询时可能需要中序遍历，效率较低。此外，B+树在叶子节点中存储了所有的数据，使得排序操作更加高效。
3. 磁盘I/O优化：在数据库中，数据通常存储在磁盘上，而磁盘I/O操作是数据库性能的关键瓶颈之一。B+树的非叶子节点只存储键值信息，而实际的数据存储在叶子节点中。这种设计使得非叶子节点可以容纳更多的键值信息，从而减少了树的高度和磁盘I/O次数。此外，由于B+树的叶子节点之间通过指针相连，数据库系统可以更加高效地读取和缓存数据。
4. 平衡性：B+树在插入和删除节点时能够保持较好的平衡性，避免了树的高度过度增长。这种平衡性保证了查询性能的稳定性，不会因为数据的插入和删除操作而产生显著的波动。

红黑树和AVL树虽然也是平衡二叉树，但在数据库环境中可能并不适用。它们的树高度相对较高，导致查询性能下降；同时，它们在处理范围查询和排序操作时效率较低。此外，红黑树在插入和删除节点时需要调整树的结构以保持平衡，这也会增加额外的开销。

学习指引：为什么mysql索引底层使用的是B+树存储，而不是红黑树吗？

3. 说说 MySQL语句的执行过程?

解析：

MySQL 的基础题，常考题。

参考回答：

MySQL语句的执行过程涉及多个关键阶段，以下是其大致的执行流程：

1. 客户端发送SQL语句： 当用户在客户端（如MySQL命令行工具、图形化界面工具等）输入SQL语句并执行时，这条语句首先被发送到MySQL服务器。
2. 词法解析和语法解析： MySQL服务器接收到SQL语句后，首先会进行词法解析，将SQL语句拆分成一个个的词汇单元（如关键字、表名、列名等）。接着进行语法解析，根据MySQL的语法规则判断这条SQL语句是否合法，并生成一个“解析树”。
3. 预处理： 在语法解析之后，MySQL会进行预处理阶段。这个阶段会检查SQL语句中涉及的表、列等是否存在，并解析权限。如果涉及存储过程、函数或触发器，也会在这一阶段进行预处理。
4. 优化器优化： MySQL查询优化器会对解析树进行优化，选择最高效的执行计划。它会考虑多种因素，如表的大小、索引、统计信息等，以决定如何最快地获取查询结果。
5. 生成执行计划： 优化器根据优化结果生成一个详细的执行计划，这个计划描述了如何获取数据、如何连接表、如何排序等。
6. 执行引擎执行： 执行引擎按照执行计划开始执行。它可能会与存储引擎交互，从磁盘上读取数据、写入数据或更新数据。如果涉及多个表，执行引擎还会负责表的连接操作。
7. 返回结果： 执行引擎将查询结果返回给客户端。这个结果可能是查询到的数据行，也可能是受影响的行数（如INSERT、UPDATE、DELETE操作）。
8. 清理： 查询执行完毕后，MySQL会进行清理工作，如释放内存、关闭临时表等。

在整个过程中，MySQL还会涉及一些日志的写入，如二进制日志（用于复制和恢复操作）、慢查询日志（记录执行时间较长的查询）等。此外，如果开启了事务，还会涉及事务的管理和锁定机制。

学习指引：【SQL】Mysql中一条sql语句的执行过程

4. MySQL有缓存吗?

解析：

考察 MySQL 的基础，属于中等难度题。

参考回答：

MySQL有缓存机制。MySQL数据库会缓存已经执行过的SQL语句和语句执行结果。如果下次提交同一个SQL语句，MySQL就会直接从缓存中读取执行结果，而不是重新分析、执行SQL，这样可以减少SQL语句的执行时间，提高查询效率。

但是，如果表中的数据发生变化，所有与之相关的缓存都会被释放刷新，以避免出现数据脏读问题。此外，MySQL也提供了手动选择是否使用缓存查询的功能，可以在SQL查询语句的字段前增加SQL_NO_CACHE或SQL_CACHE关键字来控制是否使用缓存。

总的来说，MySQL的缓存机制是其性能优化的一部分，有助于提高查询速度和效率。然而，需要注意的是，缓存并不总是有利的，特别是在数据频繁变化的情况下，因此需要根据实际情况合理使用和管理缓存。

学习指引：[玩转MySQL之四]MySQL缓存机制

5. MySQL的事务说一下?

解析：

考察数据库基础知识，必考题。

参考回答：

MySQL的事务（Transaction）是数据库管理系统执行过程中的一个逻辑单位，它由一个或多个SQL语句组成，这些语句要么全部执行，要么全部不执行。事务的主要目的是确保数据的完整性和一致性，在并发操作中保持数据的正确状态。

事务具有以下四个关键特性，通常被称为ACID特性：

1. 原子性（Atomicity）：事务被视为一个不可分割的工作单位，事务中包括的诸操作要么都做，要么都不做。
2. 一致性（Consistency）：事务必须使数据库从一个一致性状态变换到另一个一致性状态。这意味着一个事务在执行前后，数据库都必须处于一致性状态。
3. 隔离性（Isolation）：在事务执行过程中，其他事务不能访问该事务的数据，直到该事务完成。这确保了并发执行的事务不会相互干扰。
4. 持久性（Durability）：一旦事务提交，则其结果就是永久性的，即使系统崩溃也不会丢失。

在MySQL中，特别是InnoDB存储引擎，事务得到了全面的支持。当你在InnoDB中执行一个事务时，可以包含多个SQL语句，这些语句要么全部成功，要么在发生错误时全部回滚（撤销）。这通过维护一个撤销日志（undo log）来实现，当事务需要回滚时，可以利用这个日志将数据恢复到事务开始之前的状态。

此外，MySQL还提供了事务控制语句，如COMMIT和ROLLBACK，来显式地提交或回滚事务。COMMIT用于提交事务，即将事务中的修改永久保存到数据库中；而ROLLBACK则用于撤销事务中的修改，将数据库恢复到事务开始之前的状态。

学习指引：MySQL事务【详解-最新的总结】

6. Spring 的事务和我们 MySQL的事务是一回事吗?

解析：

考察Spring和MySQL的对比，需要了解。

参考回答：

Spring 的声明式事务和数据库的事务并不是一回事，尽管它们在某些方面存在关联。

声明式事务是 Spring 框架提供的一种机制，用于在应用程序中管理事务的执行。它允许你通过配置方式定义事务的行为，而无需显式编写事务管理代码。声明式事务可以应用于多个业务方法，而不仅仅是数据库操作。

数据库的事务是数据库引擎提供的一种机制，用于确保数据库操作的原子性、一致性、隔离性和持久性（ACID 特性）。数据库事务通常用于在数据库操作期间维护数据的完整性和一致性。它可以包含多个数据库操作，并且在事务执行期间，这些操作要么全部提交成功，要么全部回滚到事务开始前的状态。

在 Spring 中，声明式事务可以应用于包含数据库操作的方法，以确保这些操作在事务的上下文中执行，并根据需要进行提交或回滚。

声明式事务通过将事务管理逻辑与业务逻辑分离，提供了更高层次的抽象和灵活性。它可以用于管理其他类型的事务，如消息队列、远程服务调用等。

总结来说，声明式事务是 Spring 框架提供的一种事务管理机制，可以应用于多种业务操作，包括数据库操作。而数据库的事务是数据库引擎提供的一种机制，用于确保数据库操作的一致性和完整性。Spring 的声明式事务可以管理数据库事务，但它不仅限于数据库操作。

学习指引：spring声明式事务和数据库的事务是一回事吗

7. Spring的事务什么时候会失效?

解析：

考察Spring的熟悉程度，常考题。

参考回答：

Spring的事务在多种情况下可能会失效，以下是一些常见的原因：

1. 自调用：当类中的方法调用本类中的另一个方法时，如果调用是通过this进行的（通常省略），那么此时this并不是代理对象，而是实际的类实例。因此，事务不会生效。解决这个问题的方法是，从Spring的IoC容器中获取该类的代理对象，并通过代理对象来调用方法。
2. 方法访问权限问题：Spring要求被代理的方法必须是public的。如果方法不是public的，事务将不会生效。此外，如果方法被final修饰，Spring的动态代理无法代理final方法，因此事务也会失效。
3. 数据库不支持事务：某些数据库引擎（如MySQL的MyISAM引擎）不支持事务，因此即使Spring配置了事务，这些操作也不会在事务中执行。
4. 方法没有被Spring管理：如果类没有被Spring管理（即没有添加@Controller、@Service、@Repository等注解），那么它的方法不会被Spring的事务管理器控制，因此事务不会生效。
5. 异常处理不当：如果在事务方法中发生异常，并且该异常没有被Spring的事务管理器捕获，那么事务不会回滚。此外，对于非RuntimeException（即checked异常），Spring默认不会回滚事务，除非在@Transactional注解中明确指定了rollbackFor属性。
6. 多线程调用：由于Spring的事务管理是基于ThreadLocal的，不同线程间的事务是隔离的。因此，如果在一个线程中开启事务，然后在另一个线程中执行数据库操作，那么这些操作不会参与之前线程的事务。
7. 错误的传播属性：@Transactional注解有一个propagation属性，用于指定事务的传播行为。如果使用了错误的传播属性，可能导致事务的行为不符合预期。
8. 自定义了回滚异常与事务回滚异常不一致：如果在@Transactional注解中自定义了回滚的异常类型，但实际抛出的异常与该类型不匹配，那么事务不会回滚。

学习指引：Spring事务失效场景

8. 非聚簇索引的回表机制?

解析：

考察MySQL索引，必考题。

参考回答：

非聚簇索引的回表机制是数据库查询中的一个重要概念，尤其在MySQL的InnoDB存储引擎中。以下是对非聚簇索引回表机制的详细解释：

首先，我们需要理解聚簇索引和非聚簇索引的基本区别。聚簇索引的叶子节点存储的是行记录，也就是说，数据与索引是存储在一起的。而非聚簇索引的叶子节点存储的则是主键值，也就是说，数据和索引是分开的。

当我们使用非聚簇索引进行查询时，查询过程大致如下：

1. 数据库首先在非聚簇索引中找到满足查询条件的数据行的主键值。
2. 然后，根据这些主键值，数据库需要再次回到聚簇索引（通常是主键索引）中查找相应的数据行。这个过程就像是根据一个地址（主键值）去找到实际的房屋（数据行）。

这个从非聚簇索引回到聚簇索引查找数据行的过程，就是所谓的“回表”。回表操作会增加额外的IO操作和时间开销，因为需要再次访问数据表。在大量数据或者频繁进行回表查询的场景下，这会对查询性能产生显著影响。

为了避免频繁的回表查询，一种优化策略是使用覆盖索引。覆盖索引是指查询只需要通过索引就可以返回所需要的数据，而无需回表去访问实际的数据行。这可以显著提高查询效率。

学习指引：MySQL - 聚簇索引和非聚簇索引，回表查询，索引覆盖，索引下推，最左匹配原则

9. 哪些情况下索引会失效?

解析：

考察MySQL索引失效，必考题。

参考回答：

索引失效是指在某些情况下，数据库查询无法有效利用索引来加速查询过程，从而导致查询性能下降。以下是一些常见的导致索引失效的情况：

2. 联合索引列顺序不正确：联合索引的列顺序对查询效率有重要影响。如果查询条件中经常使用的列没有放在联合索引的前面，那么索引可能无法被充分利用。
3. 索引列上使用了函数或表达式：当在索引列上应用函数或表达式时，数据库通常无法直接利用索引进行查询，从而导致索引失效。
4. 数据库表设计不合理：表设计的不合理，如包含大量不必要的字段或冗余数据，或字段类型选择不当，都可能影响索引的有效性。
5. 列类型不匹配：当查询条件中的数据类型与索引列的数据类型不匹配时，索引可能无法被使用，从而导致索引失效。
6. 使用了IS NULL或IS NOT NULL：如果索引列中包含NULL值，并且在查询条件中使用了IS NULL或IS NOT NULL，那么索引可能无法被有效利用。
7. 隐式类型转换：当查询条件中涉及到隐式类型转换时，如将字符串类型与数值类型进行比较，索引可能会失效。

为了避免索引失效，需要合理设计数据库表结构、选择适当的索引类型、定期更新数据库统计信息，并在编写查询语句时注意避免上述可能导致索引失效的操作。同时，定期监控和分析查询性能，根据需要进行索引优化和调整，也是保持索引有效性的重要措施。

学习指引：索引失效的情况及解决(超详细)

10. MQ 如何保证消息一定被消费?

解析：

MQ常考题，必会题。

参考回答：

MQ（消息队列）是一种用于在分布式系统中进行异步通信的机制。为了保证消息一定被消费，MQ 通常会采用一系列机制和技术。以下是一些常见的方法：

1. 确认机制：当消息被发送到MQ后，MQ会等待消费者的确认。消费者处理完消息后，会向MQ发送一个确认消息，表示该消息已经被成功消费。如果MQ在一定时间内没有收到确认消息，它会认为该消息没有被成功消费，然后会重新发送消息给消费者。这种机制确保了消息至少被消费一次。
2. 持久化存储：MQ 通常会将消息持久化存储到磁盘或数据库中，以防止消息丢失。即使MQ服务器宕机或重启，也能从持久化存储中恢复消息，确保消息不会被遗漏。
3. 重试机制：如果消费者在处理消息时失败，MQ会尝试重新发送消息给消费者。重试的次数和间隔可以根据需要进行配置。通过重试机制，可以确保在消费者暂时不可用或处理失败的情况下，消息仍然能够被成功消费。
4. 死信队列：对于多次尝试消费都失败的消息，MQ 可以将其发送到死信队列中。这样可以避免消息一直阻塞在正常队列中，同时也为开发者提供了处理这些消息的机会。开发者可以定期检查死信队列，对其中的消息进行特殊处理。
5. 消息幂等性：对于某些业务场景，要求即使重复消费相同的消息也不会产生副作用。这时，需要保证消息的幂等性。在消费者处理消息时，可以通过一些技术手段（如唯一ID、分布式锁等）来确保消息只被处理一次。
6. 监控和告警：MQ 通常提供监控和告警功能，可以实时监控消息的消费情况。当消息消费出现异常时，MQ会及时发出告警通知，以便开发者能够及时处理问题。

学习指引：RabbitMQ 消息可靠性的保证

11. MQ 如何保证消息消费的顺序性?

解析：

MQ常考题，必会题。

参考回答：

1. 使用单个消费者：让单个消费者处理队列中的所有消息，这样可以确保消息按照它们进入队列的顺序被处理。但是，这种方法在处理大量消息时可能会成为性能瓶颈。
2. 使用锁机制：使用锁机制可以防止多个消费者同时访问同一消息。例如，使用数据库锁或分布式锁来确保在任何时候只有一个消费者可以处理特定消息。然而，这种方法可能会增加系统的复杂性和开销。
3. 使用事务：将消息处理与事务结合使用可以确保消息的一致性和顺序性。在事务期间，消费者会锁定消息，进行一些处理，然后提交事务。如果事务失败，消息将被回滚到队列中，以便其他消费者可以重新处理。
4. 使用消息序列号：为每条消息分配一个唯一的序列号，消费者根据这个序列号来处理消息。当消费者处理完一条消息后，它可以将该序列号提交到下一个待处理的消息。这种方法可以避免消息丢失和重复处理的问题。
5. 使用可靠的消息队列：选择一个可靠的消息队列系统，如RabbitMQ或Apache Kafka，这些系统提供了消息持久化和确认机制，以确保消息不会丢失或被重复处理。
6. 限制并发处理：通过限制消费者的并发级别，可以控制同时处理多少消息。这样可以避免因同时处理大量消息而导致的问题，如死锁和竞态条件。
7. 考虑使用单向消息传递：采用单向消息传递模型，其中消息只能从生产者流向消费者，而不能返回生产者。这样可以减少因消息返回而引起的复杂性和性能问题。

学习指引：如何保证MQ中消息的顺序性？

12. 什么原因会导致 MQ 消息积压?

解析：

MQ常考题，必会题。

参考回答：

MQ消息积压是指生产者发送的消息在Broker端大量堆积，无法被消费者及时消费，导致业务功能无法正常使用。以下是一些导致MQ消息积压的常见原因：

1. 流量变大而服务器配置偏低：当消息的产生速度大于消费速度时，如果RabbitMQ服务器配置较低，就可能导致消息积压。
2. 消费者故障：如果消费者出现宕机或网络问题，导致无法及时消费消息，消息会持续堆积。
3. 程序逻辑设计问题：如果生产者持续生产消息，但消费者由于某种原因（如处理逻辑耗时过长）消费能力不足，也会造成消息积压。
4. 新上线的消费者功能存在BUG：新上线的消费者功能如果有缺陷，可能导致消息无法被正常消费，从而引发消息堆积。
5. 配置不合理：消息队列的容量设置过小或消费者的线程数设置过少，都可能导致消息积压。
6. 生产者推送大量消息：在特定场景下，如大促活动，生产者可能短时间内推送大量消息至Broker，如果消费者的消费能力不足以应对这种突发流量，也会导致消息堆积。

为了解决MQ消息积压问题，可以采取以下策略：

1. 扩容：纵向扩容，增加服务器资源，如内存和CPU；横向扩容，将单机改为集群模式，增加集群节点，并增加消费者数量。
2. 优化程序逻辑：确保生产者和消费者的逻辑设计合理，避免生产者过快生产消息或消费者处理消息过慢。
3. 监控和报警：建立有效的监控和报警机制，及时发现并解决消息积压问题。

学习指引：消息积压解决方案

13. MQ 的死信队列了解吗，有没有在项目中用过?

解析：

MQ常考题，必会题。

参考回答：

MQ的死信队列（Dead-Letter-Exchange，简称DLX）是一个在RabbitMQ中用于处理无法被正常消费的消息的机制。当消息在队列中因为某些原因（如被拒绝、过期或队列达到最大长度）而无法被消费时，它们会被发送到死信交换机，进而路由到死信队列中等待进一步处理。

以下是关于RabbitMQ死信队列的一些关键点：

1. 消息被拒绝并设置requeue为false：当消费者使用basic.reject或basic.nack方法拒绝消息，并且设置requeue参数为false时，消息不会重新入队，而是会被发送到死信交换机。
2. 消息过期：可以为队列或消息设置TTL（Time-To-Live）值，当消息在队列中的存活时间超过这个值时，消息会变为死信。
3. 队列达到最大长度：当队列中的消息数量达到最大限制，并且无法再接受新消息时，如果队列的设置是丢弃最旧的消息或者将消息转为死信，那么被丢弃或转为死信的消息会发送到死信交换机。
4. 配置死信交换机和路由：为了确保死信能够被正确处理，需要为每个业务队列配置一个死信交换机，并为死信交换机配置一个或多个路由键和队列。这样，当消息变为死信时，它们会根据配置的路由键被路由到相应的死信队列。
5. 死信队列的处理：死信队列中的消息需要被特别关注和处理，因为它们代表了系统中存在的问题或异常情况。开发者可以编写特定的消费者来监听死信队列，以便及时发现并解决这些问题。

通过合理配置和使用死信队列，可以帮助我们更好地管理和监控MQ中的消息，确保消息能够被正确处理，避免消息丢失或积压，提高系统的稳定性和可靠性。

学习指引：深入解析RabbitMQ死信队列

14. ES的深度分页怎么解决?

解析：

ES深度分页属于常考内容，难度中等。

参考回答：

ES（Elasticsearch）的深度分页问题通常是由于查询大量数据时，性能会受到影响。

1. 设置max_result_window参数：这是分页返回的最大数据量的设置。虽然这可以暂时解决问题，但随着数据量的增大，OOM（内存溢出）问题可能会更加严重。
2. 设置数据限制：参考一些大型互联网公司（如淘宝、百度、谷歌等）的做法，对于越往后的数据，其对用户的影响通常越小，因此可以限制返回的数据量。
3. 滚动查询（Scroll Search）：滚动查询通过保存快照，并在查询时通过快照获取数据。然而，这种查询方式对Client端并不友好，因为数据的更新、删除和新增都不会影响快照。
4. search_after方式：这种方式是根据上一页的最后一条数据来确定下一页的位置。由于这种特殊的查询方式不支持跳页查询，只能依赖上一页的数据。

学习指引：ElasticSearch深度分页解决方案

15. ES 的写入性能调优了解吗?

解析：

ES性能调优属于常考内容，难度中等。

参考回答：

1. 批量写入：使用批量写入API可以显著提高写入性能。将多个文档一次性提交到ES，而不是逐个提交，可以减少网络开销和请求处理时间。
2. 刷新间隔：ES默认每秒自动刷新一次索引，可以通过增加刷新间隔来提高写入性能。刷新间隔越长，写入性能越高，但是数据的可见性会有所延迟。
3. 副本数：副本是ES中用于提高数据冗余和可用性的机制。增加副本数可以提高读取性能，但会降低写入性能。可以根据需求权衡副本数和写入性能。
4. 索引分片：ES将索引分成多个分片，每个分片可以独立地进行读写操作。增加分片数可以提高写入性能，但也会增加集群的负载和资源消耗。需要根据集群规模和硬件配置来确定合适的分片数。
5. 硬件优化：使用高性能的硬件可以提升ES的写入性能。例如，使用SSD硬盘可以加快磁盘写入速度，增加内存可以提高缓存效果。
6. 禁用不必要的功能：ES提供了许多功能和插件，但并不是所有功能都对写入性能有利。禁用不必要的功能和插件可以减少系统开销，提高写入性能。
7. 异步写入：使用异步写入机制可以将写入操作放入后台线程进行处理，提高写入性能。但需要注意异步写入可能会导致数据丢失的风险，需要根据业务需求进行权衡。

学习指引：ES写入性能优化方案

16. MyBatisPlus 遇到慢 SQL怎么排查?

解析：

MyBatisPlus常考题，必会题。

参考回答：

1. 确认是否是慢SQL：首先，确认是否真的是SQL语句导致了性能问题。可以通过日志或者性能监控工具来查看具体的SQL执行时间和性能指标。
2. 分析SQL语句：仔细分析慢SQL语句，检查是否存在不必要的查询、多表关联、大数据量操作等问题。可以使用数据库的查询分析工具（如EXPLAIN）来查看SQL的执行计划，判断是否存在索引缺失、全表扫描等性能问题。
3. 检查索引：确保数据库表中的相关字段都有适当的索引。索引可以加快查询速度，减少数据库的IO操作。可以通过数据库的索引优化工具或者命令来检查索引的使用情况。
4. 优化SQL语句：根据分析结果，对慢SQL进行优化。可以考虑使用合适的索引、优化查询条件、减少不必要的字段查询等方式来提高SQL的执行效率。
5. 使用缓存：如果某些查询结果是经常被使用的，可以考虑使用缓存来提高查询性能。MyBatis Plus提供了缓存的支持，可以配置二级缓存或者使用其他缓存框架（如Redis）来缓存查询结果。
6. 调整数据库连接池：检查数据库连接池的配置参数，确保连接池大小、最大连接数等参数设置合理。过小的连接池可能导致连接等待，从而影响SQL的执行性能。
7. 监控和日志：使用监控工具和日志记录来跟踪SQL的执行情况和性能指标。可以使用数据库的性能监控工具、MyBatis Plus的日志配置等方式来获取更详细的信息。

学习指引：Mybatis-Plus执行超长SQL性能问题排查

17. TomCat 服务器 CPU 负载特别高，但是内存不高可能是什么问题导致的?

解析：

考察TomCat问题解决能力，需要一定知识储备。

参考回答：

当Tomcat服务器的CPU负载特别高，但内存占用并不高时，可能是以下几个问题导致的：

1. 高并发请求：如果Tomcat服务器面临大量的并发请求，CPU负载会增加。即使内存占用不高，但CPU需要处理大量的请求和线程调度，导致负载升高。
2. 长时间运行的线程：如果Tomcat中存在长时间运行的线程，例如长时间的数据库查询或者耗时的业务逻辑处理，这些线程会占用CPU资源，导致CPU负载升高。
3. 错误的配置：Tomcat的配置参数可能不合理，导致CPU负载升高。例如，线程池配置过小，无法处理大量的并发请求，导致CPU负载升高。
4. 死循环或者无限循环：代码中存在死循环或者无限循环的情况，导致CPU一直在执行循环，造成CPU负载升高。
5. 第三方库或应用的问题：某些第三方库或应用可能存在性能问题，导致CPU负载升高。可以检查是否有更新版本的库或应用可用，或者尝试禁用某些库或应用来排除问题。

针对以上问题，可以采取以下措施进行排查和解决：

• 检查Tomcat的访问日志和线程堆栈，查看是否有异常请求或者长时间运行的线程。
• 检查Tomcat的配置参数，确保线程池、连接池等参数设置合理。
• 检查应用代码，查找是否存在死循环或者无限循环的情况。
• 使用性能监控工具，分析CPU占用高的线程和方法，定位性能瓶颈。
• 更新或替换可能存在性能问题的第三方库或应用。

学习指引：[排查tomcat服务器CPU使用率过高

18. 我们的 Redis 缓存怎么保证和数据库中数据的一致性?

解析：

参考回答：

1. 先更新数据库，再更新缓存：
   • 当需要更新数据时，首先更新数据库。
   • 然后，删除或更新对应的Redis缓存项。
   • 这种方法的优点在于操作直观且简单。然而，如果第二步更新缓存失败，可能会导致数据不一致。
2. 先删除缓存，再更新数据库：
   • 当需要更新数据时，首先删除Redis缓存中的对应项。
   • 然后，更新数据库。
   • 这种方法的缺点是，在删除缓存和更新数据库之间，如果有其他线程读取数据，可能会读取到旧的、已经从缓存中删除的数据，从而导致短暂的数据不一致。
3. 延时双删策略：
   • 在更新数据库之前，先删除Redis缓存。
   • 更新数据库后，等待一段时间（这个时间通常是读操作可能的最长耗时，包括Redis主从同步、网络耗时等），然后再次删除Redis缓存。
   • 这种方法可以有效解决在更新过程中其他线程读取旧数据的问题。
4. 设置缓存过期时间：
   • 为Redis缓存项设置一个合理的过期时间。这样，即使出现不一致的情况，缓存中的数据也会在一段时间后自动失效，从而确保最终一致性。
5. 使用消息队列保证顺序：
   • 将数据库更新和缓存更新的操作放入消息队列中，确保它们按照正确的顺序执行。
   • 这种方法可以确保操作的原子性，但可能会增加系统的复杂性和延迟。
6. 分布式锁：
   • 在更新数据库和缓存的过程中，使用分布式锁来确保操作的原子性。
   • 但需要注意的是，过度使用分布式锁可能会导致性能问题。
7. 读写分离：
   • 在某些场景中，可以将读操作和写操作分离到不同的服务或数据库中。例如，写操作更新主数据库，而读操作从Redis缓存或只读副本数据库中获取数据。
8. 应用层补偿：
   • 在应用层实现补偿机制，例如监听数据库的更新事件，并在必要时主动更新或删除Redis缓存。

学习指引：如何保障数据库和redis缓存的一致性

19. Redis 什么情况会导致读写性能突然变慢?

解析：

考察Redis基础，属于常考题，必会题。

参考回答：

Redis的读写性能突然变慢可能由多种因素导致。以下是一些常见的原因：

1. 内存不足：当Redis使用的内存达到其上限时，操作系统可能会开始使用交换分区（swap），这会导致Redis的读写操作变慢。此外，如果Redis实例运行的机器内存不足，也可能导致性能下降。
2. 网络延迟：网络问题，如网络IO压力大或客户端使用短连接与Redis相连，都可能导致读写性能下降。短连接需要频繁地建立和关闭连接，增加了额外的开销。
3. 复杂命令或查询：使用复杂度高的命令或一次性查询全量数据会增加Redis的处理时间，导致性能下降。
4. 大键（bigkey）操作：操作包含大量元素或占用大量内存空间的键（bigkey）会导致性能问题。例如，删除、修改或查询bigkey时，Redis需要消耗更多的CPU和内存资源。
5. 大量键集中过期：当大量键在相近的时间点集中过期时，Redis需要处理大量的过期事件，这可能导致性能突然下降。
6. 数据持久化：当Redis数据量较大时，无论是生成RDB快照还是进行AOF重写，都会导致fork耗时严重，从而影响读写性能。此外，如果AOF的写回策略设置为always，那么每个操作都需要同步刷回磁盘，这也会增加写操作的延迟。
7. CPU绑定不合理：如果Redis实例的进程绑定到不合适的CPU核上，可能会导致性能下降。同样，如果Redis实例运行机器上开启了透明内存大页机制，也可能影响性能。
8. 硬件问题：硬件故障或性能瓶颈，如磁盘I/O速度较慢、CPU性能不足等，也可能导致Redis读写性能变慢。

学习指引：Redis变慢的五大原因以及排查方法

20. 单个 Redis 中有热 Key，压力特别大，怎么解决?

解析： 考察Redis基础，属于常考题，必会题。 参考回答：

1. 分离热 Key：
   • 将热 Key 分离出来，存储在一个独立的 Redis 实例或集群中，以减轻主 Redis 实例的负载。
   • 可以使用 Redis 的哈希标签（hash tag）功能，确保与热 Key 相关的数据也存储在同一实例或分片上，以保持数据一致性。
2. 使用更高效的数据结构：
   • 如果热 Key 对应的是复杂的数据结构（如哈希表、列表等），考虑是否可以使用更高效的数据结构或编码方式。
   • 例如，对于频繁更新的列表，可以考虑使用 Redis 的有序集合（sorted set）或跳表（skip list）数据结构。
3. 缓存热点数据：
   • 在应用层引入缓存机制，将热 Key 的数据缓存到本地缓存（如 Memcached）中，减少对 Redis 的访问。
   • 当本地缓存中的数据过期或不存在时，再从 Redis 中获取数据。
4. 分布式缓存：
   • 如果热 Key 的数据量大到单个 Redis 实例无法承载，可以考虑使用分布式缓存方案。
   • 将热 Key 的数据分散到多个 Redis 实例或分片中，通过分片键（sharding key）进行路由，实现负载均衡。
5. 使用读写分离：
   • 对于读操作特别频繁的热 Key，可以考虑使用读写分离架构，将读请求和写请求分散到不同的 Redis 实例上。
   • 写请求仍然发送到主 Redis 实例，而读请求可以发送到从 Redis 实例或从 Redis 集群中的多个节点。
6. 使用 Redis 集群：
   • 如果单个 Redis 实例已经无法满足需求，可以考虑使用 Redis 集群进行水平扩展。
   • Redis 集群可以自动将数据分散到多个节点上，实现负载均衡和高可用性。

学习指引：Redis中什么是热Key问题？如何解决热Key问题？

21. Redis 主节点宕机后，怎么恢复数据，怎么产生新的主?

解析：

考察Redis集群的稳定性，属于常考题，必会题。

参考回答：

在Redis主从架构中，当主节点宕机后，可以通过一系列机制来恢复数据并产生新的主节点，以保证数据的可用性和一致性。具体过程如下：

1. 故障检测：从节点会定期向主节点发送心跳检测包（通常是PING命令），以确认主节点的状态。如果在设定的时间内没有收到主节点的响应（PONG回复），从节点会认为主节点已经宕机。
2. 选举新的主节点：在从节点中，会按照优先级、复制偏移量等因素选举出一个新的主节点。优先级高的节点更容易被选为新的主节点，如果优先级相同，则比较复制偏移量，偏移量大的节点（即数据更完整的节点）更有可能成为新的主节点。
3. 数据同步：新的主节点一旦选举出来，其他的从节点会开始向新的主节点发送SYNC或PSYNC命令，进行数据的同步。如果是第一次同步，会使用SYNC命令进行全量同步；如果是后续同步，由于已经部分同步过数据，会使用PSYNC命令进行增量同步，只同步缺失的部分数据。
4. 客户端重定向：在故障转移过程中，客户端可能会收到一些错误响应，因为原来的主节点已经不可用。此时，客户端需要重新连接到新的主节点，或者通过代理层（如Redis Sentinel）来自动处理这种重定向。

在Redis Sentinel模式下，这一过程是自动的。Sentinel会监控主从节点的状态，当检测到主节点故障时，会自动执行故障转移，选举新的主节点，并通知客户端更新连接信息。

学习指引：Redis主节点宕机，如何处理？

22. Redis 的内存淘汰策略了解吗?

解析：

考察Redis内存淘汰策略，属于常考题，必会题。

参考回答：

1. noeviction：这是默认的淘汰策略。当 Redis 内存使用达到上限时，它不会淘汰任何数据，而是直接拒绝新的写请求（除了 DEL 和一些特定的命令）。读请求仍然会正常处理。
2. volatile-ttl：这个策略会优先淘汰那些设置了过期时间且剩余存活时间（TTL）较短的键。
3. volatile-random：这个策略会随机淘汰那些设置了过期时间的键。
4. volatile-lru：这个策略会淘汰那些设置了过期时间且最久未使用的键（使用 LRU 算法，即最近最少使用）。
5. volatile-lfu：这个策略会淘汰那些设置了过期时间且最少使用的键（使用 LFU 算法，即最近最不常用）。
6. allkeys-lru：这个策略会淘汰整个数据集中最久未使用的键（使用 LRU 算法）。
7. allkeys-random：这个策略会随机淘汰数据集中的任意键。
8. allkeys-lfu：这个策略会淘汰整个数据集中最少使用的键（使用 LFU 算法）。

学习指引：Redis 内存淘汰策略 （史上最全）

更多面经直通车

原贴连接