小菜鸟

MySQL 高级语句：冲突处理、表操作与数据导入导出

在日常数据库操作中，除了基础的增删改查，还会遇到主键冲突处理、表备份、数据迁移等场景。MySQL 提供了一系列高级语句来简化这些操作，本文详细解析常用高级语句的用法与场景。

主键 / 唯一键冲突处理语句

当插入数据时遇到主键（PRIMARY KEY）或唯一键（UNIQUE）冲突，MySQL 提供了三种处理方式，避免直接报错。

1. INSERT IGNORE INTO：冲突时忽略插入

• 作用：若插入的数据与现有主键 / 唯一键冲突，则忽略当前插入操作（不报错，也不修改数据）。
• 适用场景：希望保留旧数据，跳过重复插入的场景（如批量导入时去重）。

示例：

-- 表结构（id为主键）
CREATE TABLE staff (
  id INT PRIMARY KEY,
  name VARCHAR(50),
  age INT
);

-- 初始数据
INSERT INTO staff VALUES (1, '张三', 20);

-- 插入冲突数据（id=1已存在）
INSERT IGNORE INTO staff VALUES (1, '李四', 25);  -- 无报错，数据不变
SELECT * FROM staff;  -- 仍为 (1, '张三', 20)

2. INSERT ... ON DUPLICATE KEY UPDATE：冲突时更新

• 作用：若插入冲突，则执行 UPDATE 语句更新指定字段（保留旧数据的部分字段，更新其他字段）。
• 适用场景：需要用新数据更新旧数据的场景（如用户信息更新）。

示例：

Spring Boot 自动配置原理详解：从注解到源码的全链路拆解

Spring Boot 的 “自动配置” 是其核心特性之一，本质是通过 “约定大于配置” 的思想，在启动时自动加载符合条件的配置类，减少手动 XML/Java 配置。本文基于 Spring Boot 2.x 版本，从 “入口注解→核心选择器→配置加载→条件过滤→上下文触发” 五个维度，彻底拆解自动配置的底层逻辑，帮你理解 “为什么引入依赖就能自动生效”。

自动配置的入口：@SpringBootApplication 组合注解

自动配置的起点是启动类上的 @SpringBootApplication 注解 —— 它并非单一注解，而是 @Configuration + @EnableAutoConfiguration + @ComponentScan 的组合，其中 @EnableAutoConfiguration 是自动配置的 “总开关”。

1. @SpringBootApplication 源码拆解

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
// 1. 标识为 Spring Boot 配置类（本质是 @Configuration 的语义化封装）
@SpringBootConfiguration
// 2. 自动配置核心：开启并触发自动配置逻辑
@EnableAutoConfiguration
// 3. 组件扫描：扫描当前包及其子包的 @Component/@Controller/@Service 等 Bean
@ComponentScan(excludeFilters = { 
    @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),
    @Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) 
})
public @interface SpringBootApplication {
    // 排除指定的自动配置类（如 exclude = DataSourceAutoConfiguration.class）
    Class<?>[] exclude() default {};
    String[] excludeName() default {};
}

三个子注解的核心作用：

自动配置的核心：@EnableAutoConfiguration 注解

@EnableAutoConfiguration 是触发自动配置的关键，其核心逻辑是通过 @Import(AutoConfigurationImportSelector.class) 导入一个 “选择器”，由该选择器加载并筛选自动配置类。

1. @EnableAutoConfiguration 源码解析

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
// 1. 导入自动配置类选择器：AutoConfigurationImportSelector
@Import(AutoConfigurationImportSelector.class)
// 2. 自动配置包扫描（默认是启动类所在的包）
@AutoConfigurationPackage
public @interface EnableAutoConfiguration {
    // 开关：通过配置 spring.boot.enableautoconfiguration=false 关闭自动配置
    String ENABLED_OVERRIDE_PROPERTY = "spring.boot.enableautoconfiguration";
    
    // 排除不需要的自动配置类（如数据源自动配置）
    Class<?>[] exclude() default {};
    String[] excludeName() default {};
}

两个关键细节：

Spring Boot 使用外置 Tomcat 部署详解：从配置到运行全流程

Spring Boot 默认集成了嵌入式 Tomcat，可通过 java -jar 直接启动应用，但在某些场景下（如企业统一管理服务器、需要特定 Tomcat 配置），需将应用部署到外置 Tomcat 中。从 “打包方式修改→依赖调整→启动类改造→部署运行” 四个维度，详细讲解 Spring Boot 应用部署到外置 Tomcat 的完整流程，并解答常见问题，帮你顺利完成外置容器部署。

外置 Tomcat 部署的适用场景

在决定使用外置 Tomcat 前，需明确其适用场景，避免不必要的复杂配置：

• 企业级服务器管理：大型企业通常有统一的服务器集群（如 Tomcat 集群），需将应用部署到指定外置容器；
• 自定义 Tomcat 配置：需要修改 Tomcat 核心配置（如线程池、连接器、安全配置），且这些配置无法通过 Spring Boot 嵌入式容器参数覆盖；
• 多应用共享容器：多个 Spring Boot 应用共享同一个 Tomcat 实例，节省服务器资源；
• 兼容性需求：依赖特定版本的 Tomcat（如因安全漏洞需使用定制化 Tomcat 版本）。

若无需上述场景，优先使用 Spring Boot 嵌入式 Tomcat（开发效率高、部署简单）。

部署到外置 Tomcat 的核心步骤

步骤 1：修改打包方式为 WAR

Spring Boot 默认打包为 JAR（包含嵌入式容器），部署到外置 Tomcat 需改为 WAR 包（不包含嵌入式容器，仅包含应用代码）。

在 pom.xml 中修改打包类型：

Spring Cloud Stream：消息中间件的统一编程模型

在分布式系统中，消息中间件（如 RabbitMQ、Kafka）是实现服务解耦、异步通信的核心组件，但不同中间件的 API 差异较大，增加了开发和维护成本。Spring Cloud Stream 通过抽象封装，为不同消息中间件提供了统一的编程模型，屏蔽了底层细节，让开发者可以专注于业务逻辑，无需关心具体中间件的实现差异。

Spring Cloud Stream 的核心价值

Spring Cloud Stream 的核心目标是简化消息驱动的微服务开发，主要解决以下问题：

• 中间件适配复杂：统一 RabbitMQ、Kafka 等中间件的编程接口，避免为每种中间件编写特定代码；
• 消息通信标准化：定义输入 / 输出通道（Channel）作为消息收发的统一入口，简化消息流转逻辑；
• 快速集成与扩展：通过绑定器（Binder）机制灵活切换中间件，无需修改业务代码。

核心组成与概念

Spring Cloud Stream 的架构围绕绑定器（Binder）、通道（Channel） 和消息处理器展开，核心组件如下：

绑定器（Binder）

• 定义：连接应用程序与消息中间件的桥梁，负责消息的生产者 - 消费者绑定、消息格式转换等底层操作。
• 作用：屏蔽不同中间件的实现差异（如 RabbitMQ 的 Exchange/Queue 与 Kafka 的 Topic），开发者只需通过配置指定中间件类型。
• 支持的中间件：官方支持 RabbitMQ、Kafka，社区扩展支持 RocketMQ 等。

通道（Channel）

通道是应用程序与绑定器之间的消息传输管道，分为输入通道（Input） 和输出通道（Output）：

Spring Cloud Sleuth 深入解析

什么是链路追踪？

在分布式系统中，一次用户请求可能会经过多个微服务协同处理。链路追踪就是将这一过程还原成可视化的调用链路，集中展示各服务节点的耗时、请求路径、状态等信息，帮助开发者快速定位分布式系统中的问题（如延迟过高、服务故障等）。

Spring Cloud Sleuth 核心概念

Spring Cloud Sleuth 是 Spring Cloud 生态中负责分布式链路追踪的组件，可与 Zipkin 等工具集成，实现链路数据的收集与展示。其核心术语包括：

Span（跨度）

• 分布式追踪的基本工作单元，代表一次具体的服务调用。
• 每个 Span 用 64 位 ID 唯一标识，包含描述、时间戳、父 Span ID 等元数据。
• 链路的起点称为根 Span（Root Span），其 ID 与 Trace ID 相同。

Trace（跟踪）

• 由一组共享同一个 Root Span 的 Span 组成的树状结构，代表一条完整的分布式请求链路。
• 整个链路通过唯一的 Trace ID 标识，所有 Span 共享该 ID。

Annotation（标注）

• 用于记录 Span 中的关键事件，核心标注包括：
  • CS（Client Sent）：客户端发送请求，标志 Span 开始。
  • SR（Server Received）：服务端接收请求，SR - CS 表示网络延迟。
  • SS（Server Sent）：服务端处理完请求并发送响应，SS - SR 表示服务端处理耗时。
  • CR（Client Received）：客户端接收响应，标志 Span 结束，CR - CS 表示整个请求的总耗时。