面试总结（初稿）

你好面试官，我叫崔俊，我有三年的工作经验，毕业于沧州师范学院，学历是统招本科
个人技能方面，熟练运用spring、熟悉springboot，mybatis框架，然后数据库方面mysql，Oracle都有使用过， 
可以对数据库进行一定的优化，前端方面呢就是对vue和layui框架有一定了解，同时对 js，jq有一点了解。

工作期间做过四到五个项目，
其中包括前后端分离，前后端不分离的项目都有做过，大部分项目都是用到的springboot+mybatis的框架。
对于项目中用到的相关技术都有着不错的掌握，对于未在项目中用到的前沿技术自己私下也有去做一下了解学习，
在做过的项目中主要负责后端开发，同时也参与了部分项目的前端开发，部署，运维以及编写项目文档的工作。

我对自己的评价就是沟通能力，理解能力强，在之前的工作过程中，对业务以及需求的理解能力较强
同时学习能力强，能快速的弥补自己的不足，吃苦耐劳，对工作负责

aop和IOC概念

AOP（面向切面编程）是一种编程范式，它允许在应用程序的不同模块中提取横切关注点，这些关注点通常散布在整个代码中，
例如日志记录、性能监测、事务管理等。通过使用AOP，我们可以将这些横切关注点从核心业务逻辑中分离出来，从而实现更好的代码组织和模块化。
AOP的核心思想是通过定义切点（在代码中选择连接点）和切面（在切点周围执行的行为）来实现横切关注点的管理。

IOC（控制反转）是一种设计模式，它通过将对象的创建和依赖关系的管理交给容器来实现，而不是由应用程序显式地创建和管理对象。
在传统的编程模型中，对象之间的依赖关系通常在类内部硬编码，而使用IOC容器，我们可以通过配置文件或注解来声明对象之间的依赖关系。
这样，应用程序的不同模块之间的耦合度大大降低，更易于维护和测试。IOC容器负责实例化对象并解析它们之间的依赖关系，使得对象的创建和管理更加灵活和可扩展。

除了上述定义，你可以进一步说明AOP和IOC的优势和用途，例如：

AOP可以帮助我们实现横切关注点的复用，减少重复代码，提高代码的可维护性和可测试性。
AOP可以提供一种非侵入式的方式来添加额外的行为，而不需要修改现有的代码。
IOC可以简化对象之间的依赖关系管理，降低模块之间的耦合度，提高代码的灵活性和可扩展性。
IOC容器可以根据配置文件或注解自动解析和注入对象的依赖关系，提供更方便的对象创建和管理方式。
AOP和IOC通常在框架中广泛应用，如Spring框架，它们是实现框架功能的重要基础。
记住，在回答问题时要使用自己的话语表达，并结合自己的经验和理解来解释这些概念，以使回答更加真实和具体。

实现aop的步骤

在Spring框架中，可以通过以下步骤来实现AOP：

引入所需的依赖：首先，确保在项目的构建文件（例如Maven或Gradle）中引入Spring AOP所需的依赖项。这通常包括spring-aop和spring-context等核心模块。

定义切点（Pointcut）：切点定义了在应用程序中哪些方法或连接点应该被拦截和应用切面逻辑。可以使用基于注解或基于表达式的方式来定义切点。例如，使用@AspectJ注解或XML配置来定义切点。

编写切面（Aspect）：切面是横切关注点的具体实现，它定义了在切点处执行的逻辑。切面通常包含一个或多个通知（Advice），用于在切点的前后或周围执行额外的逻辑。通常有以下几种类型的通知：

前置通知（Before Advice）：在切点方法执行之前执行。
后置通知（After Advice）：在切点方法执行之后执行，不考虑其结果（即使方法发生异常）。
返回通知（After Returning Advice）：在切点方法成功执行并返回结果后执行。
异常通知（After Throwing Advice）：在切点方法抛出异常后执行。
环绕通知（Around Advice）：在切点方法的前后执行，可以控制切点方法的执行过程。
配置AOP：根据使用的方式（注解或XML），在配置文件或类中进行AOP配置。对于基于注解的配置，可以使用@EnableAspectJAutoProxy注解启用Spring AOP，
并将切面类标记为@Aspect注解。对于XML配置，需要配置<aop:config>元素和相关的子元素，如<aop:aspect>和<aop:pointcut>。

运行应用程序：确保将AOP配置应用于Spring应用程序上下文，并运行应用程序。当满足切点条件时，切面的逻辑将自动应用于相应的连接点。

需要注意的是，上述步骤中的具体实现方式可能因使用的Spring版本、配置方式和个人偏好而有所不同。在实际应用中，可以根据项目的需求和架构选择适合的AOP实现方式。

对 SQL 优化的了解：

当被问到对 SQL 优化的了解时，你可以采用以下方法回答：

引入 SQL 优化的概念：首先，可以简要介绍 SQL 优化是为了改进数据库查询性能和效率的过程。它涉及分析查询执行计划，优化索引和表设计，以及优化查询语句本身。

强调索引的重要性：索引是 SQL 优化的关键部分之一。它们可以加快查询速度并减少数据库的负载。可以提到如何选择和创建适当的索引，以及如何根据查询的特点进行索引优化。

提及查询语句的优化方法：解释如何重写查询语句以提高性能。这可能包括使用合适的连接类型（如 INNER JOIN、LEFT JOIN），避免使用子查询，减少不必要的列选择等。

讨论查询执行计划：查询执行计划是查询优化的关键部分。可以提到如何使用 EXPLAIN 或类似的工具来分析查询执行计划，了解查询是如何执行的，是否存在性能瓶颈，并根据需要进行调整。

强调避免全表扫描：全表扫描是一种低效的查询方式，特别是对于大型表格。可以提到如何使用索引、分区表或其他方法来避免全表扫描，从而提高查询性能。

谈论统计信息的重要性：统计信息提供了关于数据库中数据分布和表的信息。可以强调如何更新统计信息以保持查询优化的效果，并且如何使用收集到的统计信息来帮助优化查询执行计划。

提及数据库引擎优化器：数据库引擎中的优化器负责生成最佳查询执行计划。可以简要讨论如何理解和影响优化器的行为，例如使用查询提示（query hints）来指导优化器选择合适的执行计划。

强调测试和监测的重要性：在进行 SQL 优化时，测试和监测是至关重要的。可以提到如何设计和执行基准测试来评估不同优化方法的性能，并使用监控工具来跟踪查询性能和优化效果。

数据库分库分表

数据库分库分表是一种常见的数据库性能优化策略，它将一个大型数据库拆分成多个较小的数据库，同时将表拆分成多个较小的表，以提高数据库的并发处理能力和查询性能。下面是数据库分库分表的一般操作步骤：

数据库设计和规划：
分析应用程序的访问模式，确定需要拆分的数据库和表。
考虑拆分策略，如垂直拆分（按功能或业务拆分）和水平拆分（按数据行拆分）。
设计数据库拆分方案，确定每个分片（shard）的数据量和拆分规则。

数据迁移：
创建新的数据库和表结构，准备用于存储分片数据的数据库和表。
将现有数据从原始数据库迁移到新的数据库和表中。
可以使用ETL（Extract, Transform, Load）工具或自定义脚本来执行数据迁移操作。

应用程序适配：
修改应用程序的数据库连接配置，使其能够连接到新的分片数据库。
根据拆分规则，调整应用程序的数据访问逻辑，确保正确地访问和操作分片数据。

数据同步和一致性：
如果需要跨分片查询或事务操作，需要考虑数据同步和一致性问题。
可以采用同步机制，如主从复制或分布式事务，确保数据在分片之间的一致性。

性能监控和调优：
针对分库分表后的系统，进行性能监控和调优。
监控数据库的负载情况、查询性能和响应时间，根据需要进行调整和优化。
需要注意的是，数据库分库分表是一个复杂的过程，需要仔细规划和测试，以确保正确性和可靠性。在进行分库分表之前，建议先进行充分的需求分析和评估，
以确定是否真正需要进行分库分表，并根据实际情况选择适合的分片策略和工具。

当涉及消息队列（MQ）消息丢失的面试题时，以下是一些常见的问题和答案：

什么是消息丢失？
消息丢失是指在消息队列系统中，消息在发送和接收过程中意外丢失或丢失的现象。这可能由于网络故障、生产者或消费者错误、消息队列系统故障等原因导致。

造成消息丢失的常见原因有哪些？
消息丢失可能由以下原因引起：
网络故障：在消息传输过程中，网络中断或连接问题导致消息丢失。
消息队列系统故障：消息队列系统本身出现故障，导致消息丢失。
消费者错误：消费者未正确处理消息或异常终止，导致消息丢失。
生产者错误：生产者未能正确发送消息或异常终止，导致消息丢失。
消息过期：消息在队列中过期后被自动丢弃。

如何避免消息丢失？
避免消息丢失可以采取以下措施：
持久化消息：使用持久化消息特性，确保消息在发送和接收过程中持久存储。
事务机制：使用事务来保证消息的可靠传输，生产者和消费者在事务中提交或回滚消息。
消息应答机制：消费者接收并处理消息后，发送应答确认给消息队列，确保消息被成功消费。
异常处理和重试：当发生错误或异常时，实现适当的错误处理和消息重试机制，确保消息不会丢失。
监控和报警：实施监控和报警机制，及时发现消息丢失或异常情况，并采取相应的处理措施。

如何处理已经发生的消息丢失？
处理已经发生的消息丢失可以考虑以下方法：
日志记录：在生产者和消费者中实施日志记录，记录发送和接收的消息，以便后续追踪和排查。
消息重放：如果消息丢失是暂时性的，可以尝试重新发送丢失的消息，确保其被正确处理。
容错和补偿机制：在系统中实施容错和补偿机制，通过补偿逻辑或重试机制来处理消息丢失的情况。
这些问题涵盖了消息队列中消息丢失的基本概念和处理方法。在面试中，可能会进一步探讨消息可靠性保证、幂等性、消息队列系统的故障处理等方面的问题

动态数据源（动态数据源没有使用mybatis配置，而是通过数据源配置类，在配置进行配置，然后用户选择在系统中配置数据源，配置完后可以选择，同时存进数据库，在用户请求接口时动态刷新），
优化sql(在项目交付后的维护阶段，优化了查询慢的sql，将原先循环嵌套为条件的查询，改为了直接关联表查询，直接查询出结果后再在service中进行筛选)，
分页查询，
ThreadLocal（）
部署相关