数据库 on Coder_Studio

【面试真题拆解】Spring中的注解

Wed, 18 Mar 2026 08:53:48 +0000

面试官没有直接问我“@Autowired和@Resource的区别”这种题，而是：

先让我举几个Spring注解的例子，再问“Spring注解定义为什么都挺短，不会有大量代码”，直接考察你对注解本质和Spring AOP/IOC底层的理解。

举几个Spring注解的例子

1. IOC依赖注入类注解

注解	作用	区别
@Autowired	Spring原生注解，按类型（byType）自动注入依赖	优先byType，找不到唯一Bean时，会尝试按变量名（byName）匹配；可以配合 `@Qualifier` 指定Bean名称；可以用 `required=false` 允许依赖为空
@Qualifier	配合 `@Autowired` 使用，强制按名称（byName）注入依赖	当容器中有多个同类型Bean时，必须用它指定具体用哪个
@Resource	按名称（byName）优先注入，找不到再按类型（byType）匹配	JSR-250标准，跨框架兼容性好；可以用 `name` 属性显式指定Bean名称

2. IOC组件注册类注解

注解	作用
@Component	通用组件注册注解，把任意类标记为Spring容器的Bean
@Controller	`@Component` 的子类，专门标记Web控制器层的Bean
@Service	`@Component` 的子类，专门标记业务逻辑层的Bean
@Configuration	`@Component` 的子类，专门标记Java配置类，替代XML配置文件
@Repository	@Component 的子类，专门标记数据访问层的 Bean；还能把数据库的异常（如 SQLException）转换成 Spring 的 DataAccessException（非受检异常）

3. AOP切面类注解

横切关注点就是“和业务逻辑无关，但很多地方都要用的功能”，比如日志、事务、权限校验、性能监控这些。

注解	作用
@Aspect	把类标记为切面类
@Pointcut	定义切入点表达式，告诉Spring“哪些方法需要被增强”
@Before	前置通知：在目标方法执行之前执行增强逻辑
@After	后置通知：在目标方法执行之后（不管有没有异常）执行增强逻辑
@AfterReturning	返回通知：在目标方法正常返回之后执行增强逻辑
@AfterThrowing	异常通知：在目标方法抛出异常之后执行增强逻辑
@Around	环绕通知：最强大的通知，可以完全控制目标方法的执行（比如不执行目标方法、修改参数、修改返回值）

Lombok的常用注解

Lombok是一种代码简化工具，通过注解自动生成代码。

虽然不是Spring原生注解，但Lombok的注解是Java开发中经常会用到的。

注解	作用
@Slf4j	自动生成 SLF4J日志对象
@Data	自动生成 getter/setter、toString、equals、hashCode、无参构造器
@NoArgsConstructor	自动生成无参构造器
@AllArgsConstructor	自动生成全参构造器

Spring 注解定义为什么通常都挺短，不会有大量代码？

面试官这么问主要是想考察你对注解本质和Spring容器底层的理解。

先明确一下元数据（Metadata）的定义，元数据就是“描述数据的数据”，本身不是数据的内容，只是给数据打标签、加属性。

根本原因在于注解只是元数据标记，本身不包含任何逻辑。

举个Spring注解的例子，比如 @Transactional：

// @Transactional的核心定义（简化版，去掉了很多元注解和属性）
@Target({ElementType.METHOD, ElementType.TYPE}) // 元注解：标记这个注解能用在方法/类上
@Retention(RetentionPolicy.RUNTIME) // 元注解：标记这个注解保留到运行时
@Inherited // 元注解：标记这个注解可以被子类继承
@Documented // 元注解：标记这个注解会被生成到JavaDoc里
public @interface Transactional {
    // 只有属性，没有任何方法/逻辑！
    String value() default ""; // 事务管理器的名称
    Propagation propagation() default Propagation.REQUIRED; // 传播行为
    Isolation isolation() default Isolation.DEFAULT; // 隔离级别
    int timeout() default -1; // 超时时间
    boolean readOnly() default false; // 是否只读
}

可以看到@Transactional 的定义里只有属性，没有任何一行业务逻辑或容器逻辑。

它只是告诉Spring容器：“这个方法/类需要开启事务，传播行为是REQUIRED，隔离级别是DEFAULT…”，真正开启/提交/回滚事务的逻辑，全在Spring的事务管理器和AOP切面里。

除此之外，Spring注解的定义比较短，还有一个原因是Spring大量使用了元注解（Meta-Annotation）。

那什么是元注解呢？

元注解就是“标记注解的注解”，可以复用已有注解的功能，不用重复写代码。

比如上面的 @Transactional，它上面有@Target、@Retention、@Inherited、@Documented这4个元注解。

怎么自定义一个Spring注解？

简单来说有以下3步：

定义注解

用 @interface 定义，加上JDK原生元注解（至少需要 @Target 和 @Retention(RUNTIME)）；

编写后置处理器

实现 BeanPostProcessor 或 BeanFactoryPostProcessor 接口，或者用 AOP 切面（更适合方法级别的拦截，比如权限校验、记录执行时间），处理自定义注解的逻辑；

注册后置处理器

把自定义后置处理器交给Spring容器管理（比如用 @Component 标记）。

举个例子@AuthCheck：

@Target(ElementType.METHOD)
//规定这个标签能贴在哪里,ElementType.METHOD 意思是“只能贴在方法上面”。
@Retention(RetentionPolicy.RUNTIME)
//规定这个标签的有效期,RUNTIME的意思是“程序运行的时候，这个标签依然存在”
public @interface AuthCheck {

    /**
     * @interface 不是接口（interface），而是专门用来定义注解的语法。
     * String mustRole()：表示用这个标签时，
     * 你可以写上一个角色名，比如 @AuthCheck(mustRole = "admin")。
     * default ""：如果你只写了 @AuthCheck
     * 而没填角色，那默认值就是一个空字符串 ""
     * （表示不需要特定角色，只要登录就行，具体看你怎么实现业务逻辑）。
     *
     */
    String mustRole() default "";
}

MySQL的三层B+树能存多少数据？

Mon, 16 Mar 2026 13:09:19 +0000

InnoDB读写磁盘的最小单位是页（Page），默认大小16KB。
而MySQL的主键索引B+树，每一个树节点（不管是根节点、中间节点、叶子节点），本质上就是一个16KB的页。
所有计算，都是围绕【1个16KB的页，能存多少东西】展开的。

节点类型	存的内容	特点
非叶子节点（根节点、中间层节点）	只存主键值 + 指向下一层页的指针	不存完整用户数据，体积极小，一个页能存上千个
叶子节点（最底层节点）	存用户的完整一行行数据	存真实业务数据，体积大，一个页能存的行数有限

1.先算1个非叶子节点，能存多少个索引项

非叶子节点存的是「主键值 + 指针」，我们先算单个索引项的大小：

主键大小：假设主键是bigint类型，MySQL里bigint固定占8字节；
指针大小：InnoDB里指向页的指针，固定占6字节；
单个索引项总大小：8字节（主键） + 6字节（指针） = 14字节。

一个页是16KB，换算成字节是 16 × 1024 = 16384字节。
所以一个非叶子页能存的索引项数量：
16384 ÷ 14 ≈ 1170个

2.再算1个叶子节点，能存多少行数据

叶子节点存的是用户的完整一行行数据，假设一行业务数据占1KB（比如一张表有id、name、age、create_time等字段，加起来差不多1KB）。

一个页是16KB，所以一个叶子页能存的行数：
16KB ÷ 1KB/行 = 16行

3.最后算三层B+树的总数据量

顺着三层结构，从根节点往下算：

第一层（根节点）：1个非叶子页，能存1170个索引项 → 能指向1170个第二层的页；
第二层（中间非叶子节点）：1170个非叶子页，每个页又能存1170个索引项 → 能指向 1170 × 1170 = 1368900 个第三层的叶子页；
第三层（叶子节点）：每个叶子页能存16行数据。

最终总数据量 = 叶子页总数 × 每个叶子页的行数：
1170 × 1170 × 16 ≈ 2190万条

所以，三层B+树大约能存2000万条记录。

【面试真题】能讲讲MySQL的锁机制吗

Sun, 15 Mar 2026 16:44:46 +0000

MySQL的锁按两个维度分，刚好对应开发中最常遇到的问题：

按解决并发冲突的思路分，是悲观锁和乐观锁——这俩决定了“你是先占坑再干活，还是先干活最后再检查”；

按锁的范围大小分，是表锁、行锁，还有 InnoDB 特有的间隙锁 + 临键锁 —— 这三类锁决定了 “你是锁整个仓库（表锁）、只锁你要的那一件商品（行锁），还是锁仓库里的某个货架区间（间隙锁 + 临键锁）”。

先建一张最简单的电商商品表 product，插几条测试数据，等会更好理解举的例子：

CREATE TABLE `product` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键ID',
  `name` varchar(100) NOT NULL COMMENT '商品名称',
  `stock` int(11) NOT NULL DEFAULT '0' COMMENT '库存',
  `version` int(11) NOT NULL DEFAULT '0' COMMENT '乐观锁版本号',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品表';

-- 插入测试数据：id=1是iPhone，库存100；id=3是华为，库存200；id=5是小米，库存150
INSERT INTO `product` (`id`, `name`, `stock`, `version`) VALUES
(1, 'iPhone 17', 100, 0),
(3, 'Mate 70', 200, 0),
(5, 'Xiaomi 15', 150, 0);

悲观锁

举个电商秒杀扣库存的真实例子，也是悲观锁最典型的应用：

比如有两个用户同时秒杀iPhone 17，库存100。

如果不用锁，俩人同时查出来库存100，都扣减1，就超卖了。
用悲观锁的话，就是在查库存的时候用 SELECT ... FOR UPDATE 显式加排他锁——

第一个用户的事务先把这行数据锁住，第二个用户的查询就会阻塞，等第一个用户扣减完库存、提交事务释放锁，第二个用户才能拿到最新的库存，这样就保证了不超卖。

乐观锁

这也是开发中很常见的场景：两个运营同时修改同一件商品的标题。

这种场景并发冲突概率很低（因为很少会有两个人同时改同一个商品的标题），如果用悲观锁，每次修改都要加锁，太影响性能了，所以用乐观锁更合适。

乐观锁的意思就是：我假设没人跟我抢，所以我先直接修改，最后提交的时候再检查一下：

在我修改的这段时间里，有没有别人也改过这条数据？

如果没有，就修改成功；

如果有，就提示用户“数据已被修改，请刷新后重试”。

举个具体的SQL操作实例

我们打开两个命令行窗口，分表代表两个会话。

1.会话A（运营A先查商品）

1
2

-- 1. 运营A查出来iPhone的信息，此时 version = 0
SELECT * FROM product WHERE id = 1;

2.会话B（运营B同时查商品）

1
2

-- 1. 运营B也查出来iPhone的信息，此时 version 也是 0
SELECT * FROM product WHERE id = 1;

3.会话A（运营A先提交修改）

-- 1. 运营A把标题改成“iPhone 17 Pro Max”，WHERE条件带上 version = 0
UPDATE product 
SET name = 'iPhone 17 Pro Max', version = version + 1 
WHERE id = 1 AND version = 0;
-- 现象：返回更新行数为 1，修改成功！此时数据库里的 version 变成了 1

4.会话B（运营B后提交修改）

-- 1. 运营B把标题改成“iPhone 17 特价版”，WHERE条件也带上 version = 0
UPDATE product 
SET name = 'iPhone 17 特价版', version = version + 1 
WHERE id = 1 AND version = 0;
-- 现象：返回更新行数为 0，修改失败！
-- 因为数据库里的 version 已经变成 1 了，找不到 id=1 AND version=0 的行
-- 此时业务代码就可以提示用户：“商品已被其他运营修改，请刷新页面后重试”

表锁

直接锁整张表，其他会话对这张表的任何读写（不管是查哪一行、改哪一行）都会被阻塞。

举个例子

-- 会话A：给全表商品库存+10，显式加表锁
LOCK TABLES product WRITE;
UPDATE product SET stock = stock + 10;

-- 此时会话B想查id=1的商品，会直接阻塞！
SELECT * FROM product WHERE id = 1;

-- 会话A提交事务并释放表锁后，会话B才能执行
UNLOCK TABLES;

表锁的优点是加锁开销小、速度快，不会死锁，但缺点就是并发度极低，一锁全表，电商场景下用它会直接让网站卡死。

行锁

只锁具体的某一行数据，其他行完全不受影响，是InnoDB支持高并发的核心。

需要注意的是行锁的前提是【走索引】。

如果你的查询没走索引，InnoDB会退化成表锁。

举两个例子对比一下

先看走索引的情况（行锁生效）：

-- 会话A：用主键id=1查，加排他锁（走主键索引，只锁id=1这行）
BEGIN;
SELECT * FROM product WHERE id = 1 FOR UPDATE;

-- 会话B：查id=3的商品，完全不阻塞！直接拿到锁
BEGIN;
SELECT * FROM product WHERE id = 3 FOR UPDATE; -- 执行成功

-- 会话B：查id=1的商品，会阻塞！需要等会话A释放锁
SELECT * FROM product WHERE id = 1 FOR UPDATE; -- 阻塞

再看没走索引的情况（退化成表锁）：

-- 先确认name字段没加索引（前面建表的时候只给id加了主键）
-- 会话A：用name='iPhone 17'查，加排他锁（没走索引，锁全表！）
BEGIN;
SELECT * FROM product WHERE name = 'iPhone 17' FOR UPDATE;

-- 会话B：查id=3的商品，居然也阻塞了！因为锁了全表
BEGIN;
SELECT * FROM product WHERE id = 3 FOR UPDATE; -- 阻塞

行锁的优点是并发度极高，只锁需要的行，不影响其他操作；但缺点是加锁开销大、速度慢，可能产生死锁。

间隙锁+临键锁

这俩是InnoDB特有的，专门用来解决【幻读】问题的。

先举个电商场景的例子说明一下什么是幻读？

-- 会话A：查id>1的所有商品（此时表里只有id=1、3、5）
BEGIN;
SELECT * FROM product WHERE id > 1 FOR UPDATE; -- 第一次查：查到id=3、5两条

-- 会话B：插了一条id=2的商品，提交事务
INSERT INTO product (id, name, stock, version) VALUES (2, 'OPPO Find X8', 100, 0);
COMMIT;

-- 会话A：再查id>1的商品，居然查到了id=2、3、5三条！
SELECT * FROM product WHERE id > 1 FOR UPDATE; -- 第二次查：多了一条，像产生了幻觉

这就是幻读：同一个事务里，两次相同的范围查询，结果却是不一样的。

间隙锁（Gap Lock）

间隙锁，间隙锁，顾名思义，它不锁具体的行，锁的是两个索引值之间的“间隙”，也就是只锁两个相邻索引值之间的空白区间，以防止别人在这个区间里插数据。

以刚开始建的那个product表为例：

id=1、3、5，间隙就是：(-∞,1)、(1,3)、(3,5)、(5,+∞)。

临键锁（Next-Key Lock）

临键锁其实是【行锁】+【间隙锁】的组合，锁的是左开右闭的区间。

比如(1,3]（锁id=3这一行，同时锁1到3之间的间隙）。

还是以刚开始建的那个product表为例，临键区间就是：(-∞,1]、(1,3]、(3,5]、(5,+∞)。

举个例子

-- 会话A：用id=3查，加排他锁（走主键索引，加临键锁(1,3]）
BEGIN;
SELECT * FROM product WHERE id = 3 FOR UPDATE;

-- 会话B：想插id=2的商品，直接阻塞！因为间隙(1,3)被锁了
INSERT INTO product (id, name, stock, version) VALUES (2, 'OPPO Find X8', 100, 0); -- 阻塞

-- 会话B：想插id=6的商品，不阻塞！因为(5,+∞)没被锁
INSERT INTO product (id, name, stock, version) VALUES (6, 'Vivo X200', 100, 0); -- 执行成功

小贴士

间隙锁 + 临键锁只在 InnoDB 的默认隔离级别【可重复读（RR）】下生效。

如果是【读提交（RC）】隔离级别，会关闭间隙锁，只保留行锁。

夺命连环问：什么是死锁？又怎么避免呢？

两个或多个会话，互相持有对方需要的锁，都在等待对方释放，导致谁都执行不下去，形成“死循环”，这就是死锁。

举个例子

-- 会话A：先锁id=1，再想锁id=3
BEGIN;
SELECT * FROM product WHERE id = 1 FOR UPDATE; -- 持有id=1的锁
-- 此时会话A想拿id=3的锁，但被会话B持有了，阻塞
SELECT * FROM product WHERE id = 3 FOR UPDATE; -- 阻塞

-- 会话B：先锁id=3，再想锁id=1
BEGIN;
SELECT * FROM product WHERE id = 3 FOR UPDATE; -- 持有id=3的锁
-- 此时会话B想拿id=1的锁，但被会话A持有了，阻塞
SELECT * FROM product WHERE id = 1 FOR UPDATE; -- 阻塞

-- 结果：死锁！

死锁的四个必要条件

只要破坏其中任意一个，就能避免死锁：

互斥条件：一个锁只能被一个会话持有（行锁就是这样，没法破坏）；
请求与保持条件：持有一个锁的同时，又请求另一个锁；
不剥夺条件：锁只能由持有者主动释放，不能被别人强行抢走；
循环等待条件：会话之间形成循环等待链（A等B，B等A）。

怎么避免死锁？

① 按固定顺序加锁

所有会话都按相同的顺序加锁，比如都先锁id小的，再锁id大的，这样就不会形成循环等待。

② 减少锁的范围和持有时间

尽量用行锁不用表锁；

事务尽量小，不要在事务里做无关操作（比如不要在事务里调第三方接口、查无关表），锁持有时间越短，死锁概率越低。

③ 避免大事务

大事务持有锁的时间长，涉及的行多，更容易死锁，把大事务拆成多个小事务。

小贴士

InnoDB 有自动死锁检测机制，它会实时扫描锁等待链，一旦发现死锁，会自动回滚其中一个，一般是代价较小的那个事务，比如更新行数少的那个，让另一个事务继续执行，不会让系统无限期卡死。

【面试真题】缓存和数据库的一致性问题如何保证？

Fri, 13 Mar 2026 14:14:10 +0000

坦白说，这个问题本质上不是个纯技术方案题，而是高并发场景下，平衡【性能、可用性、一致性强度】的工程题。

核心是先看业务的一致性容忍度，再选对应方案，而且必须做好异常兜底，不然线上一定会出永久脏数据。

在电商场景中，绝大多数情况下优先保证最终一致性，只有金融级核心链路才会考虑强一致性。

先说标准流程：

读请求：先查缓存，命中直接返回；没命中就读数据库，把结果写回缓存再返回。
写请求：先更新数据库，再删除缓存。

为什么是【删除缓存】，而不是【更新缓存】？

一是并发写场景下，更新缓存一定会有数据覆盖的风险；

二是电商场景很多缓存值是多表关联算出来的，更新缓存的成本极高，不如删除后懒加载；

三是写多读少的场景，频繁更新缓存全是无效操作，浪费性能。

为什么是【先更库，再删缓存】，不能反过来？

如果你刚把缓存删了，数据库还没更新完，这时候高并发的读请求进来，缓存查不到，直接去数据库拉了旧数据，还写回了缓存。

等你数据库更新完，缓存里的旧数据就一直躺在那，除非缓存过期，不然用户一直看到的是错的数据。

但是，如果是先更库再删缓存，只有极小概率会出问题，比如：

读请求缓存没命中，正在读数据库的瞬间，写请求更新了数据库并删了缓存，之后读请求把旧数据写回缓存。

但是，但是啊，这个场景发生的条件太苛刻了，因为写数据库的耗时远大于读数据库，基本卡不中这个时间窗口，线上出问题的概率几乎可以忽略。

就算真的撞上了，还有缓存 TTL 兜底，最多就是短时间不一致，绝对不会出永久脏数据。

其实，这个方案最大的风险，是第二步删缓存失败。

同步删缓存如果失败，立刻把这个key丢到消息队列里做异步指数退避重试，设置最大重试次数，绝对不让缓存操作阻塞主流程。

高并发下的两个进阶方案

第一个是延迟双删，解决基础方案的极端并发问题。
“针对商品详情、营销活动这种超高并发读的场景，用延迟双删做加固，流程是：

先删除缓存➡️更新数据库➡️延迟500ms-1s，二次删除缓存。
第二次延迟删除，刚好能覆盖掉【数据库更新过程中，读请求写回缓存的旧数据】，彻底解决极端并发的脏数据问题。
其中，延迟时间必须大于【业务读请求的最大耗时 + 数据库主从同步延迟】。

第二个是基于Binlog的异步缓存淘汰。
用Binlog异步淘汰缓存，完全解耦业务和缓存操作。

业务代码只做一件事：更新数据库，完全不碰缓存。

然后用Canal监听数据库的binlog增量日志，只有主库事务提交成功，才会拿到数据变更事件，再异步去删除对应的缓存key。如果删除失败，就丢进死信队列重试，超过阈值直接触发告警。

强一致性方案

只有像支付账户余额、核心库存扣减这种，一分钱都不能错、零容错的场景，才会考虑强一致性方案，因为它的性能代价极大。
用Redisson的分布式读写锁，写请求加写锁，读请求加读锁，读写互斥，强制串行化，彻底避免并发问题。

但这个方案会严重降低系统吞吐量，高并发下很容易出现锁等待、超时问题，所以非核心场景，绝对不会用。

兜底机制

不管方案设计得多完美，线上一定会有意外，比如：

缓存集群炸了、消息队列挂了、binlog消费延迟了，没有兜底，就等着出线上事故。
可以采用以下兜底策略：

TTL兜底：所有缓存key必须设置合理的过期时间，哪怕所有机制都失效了，最多就是一段时间的不一致，缓存一过期，就自动拉取最新数据，绝对不会出现永久脏数据。
失败重试机制：所有缓存删除操作，必须有异步重试兜底，不能一次失败就放任脏数据存在。
降级开关：大促场景下，如果缓存集群扛不住了，直接开降级开关，所有请求切到读数据库，先保证用户能下单，别的都好说。

Redis、内存、缓存、MySQL、数据库，这些的区别到底是什么

Sun, 01 Feb 2026 13:02:50 +0000

这几个词经常一起出现，有次面试的时候被问到了，还是有点懵的，本文就来理清一下。

1. 内存（Memory）

本质上是硬件，比如电脑/服务器上的内存条，速度极快（纳秒级），缺点是断电会导致数据丢失。

需要注意：程序运行时必须把数据加载到内存才能执行。

2. 数据库（Database）

本质上是软件，用来持久化存储数据（断电不丢失），提供查询、修改、事务等能力，数据存在硬盘。

3. MySQL

本质上是关系型数据库（ Relational Database Management System, RDBMS），数据存在硬盘，支持 SQL、事务、索引、复杂查询，速度比内存慢很多（毫秒级）。

需要注意的是MySQL 是数据库的一种，但是数据库 ≠ MySQL。

4. 缓存（Cache）

本质上其实是一种“加速思想或者机制”，不是软件也不是硬件，而是一种设计模式，主要用于把热点数据放在更快的地方，减少查询压力。

5. Redis

本质上是基于内存的 NoSQL 数据库，数据主要存在内存，也可以持久化到硬盘，常被当作分布式缓存使用。

需要注意的是：

Redis 是一个数据库，Redis ≠ 缓存，只是它常被用来做缓存，但它功能远不止缓存，比如也可以做排行榜、限流、分布式锁等等。

MySQL中有哪些日志类型？

Sat, 24 Jan 2026 15:38:05 +0000

MySQL有binlog、redo log和undo log三种日志，其中binlog 负责主从复制和数据恢复，redo log保证崩溃后数据不丢失，undo log支撑事务回滚和MVCC。

1.binlog

binlog 是server层的日志，记录的是逻辑操作，也就是原始SQL或者行变更前后的值。

它的核心场景是主从同步，从库拉取主库到binlog重放一遍就能保持数据一致。

另外，做数据恢复的时候，也是靠binlog配合全量备份回放到指定时间点。

2.redo log是InnoDB引擎独有的，记录的是物理变更，具体就是“某个数据页的某个偏移量改成了什么值”。

它的作用是崩溃恢复（crash-safe），基于WAL（Write Ahead Log）机制，MySQL挂了重启后，InnoDB会用redo log把没来得及刷盘的脏页恢复出来。

redo log是循环写的，空间固定，写满了就得等checkpoint推进才能继续。

3.undo log也是InnoDB引擎的逻辑日志，记录的是数据修改前的旧值。

事务回滚的时候，就靠undo log把数据改回去，另外MVCC的快照读也依赖它，别的事务要读历史版本，顺着undo log链往前找就行。

MySQL是怎么实现事务的？

Fri, 23 Jan 2026 15:59:01 +0000

MySQL实现事务靠的是4个核心组件：

Redo Log
Undo Log
锁
MVCC

这四个组件分别对应事务的ACID特性的不同方面，一致性是由原子性、隔离性、持久性共同作用实现的。

1.Redo Log保证持久性（D）

在事务提交时，基于WAL（预写日志）机制将修改先写到Redo Log再刷盘写磁盘数据页。

就算写数据页时宕机了，重启后通过重放redo log就能恢复数据，确保已提交的修改不会丢失。

2.Undo Log保证原子性（A）

每次修改数据前，先把原值以逻辑日志的形式存到undo log中。

事务回滚时，按undo log反向操作把数据恢复回去。

要么全做完，要么全撤销，不会出现改了一半的中间状态。

3.锁机制保证隔离性（I）的写-写并发

两个事务同时改同一行，必须一个等另一个释放锁，实现写-写互斥。

InnoDB的锁粒度精确到行级（基于索引实现），还有间隙锁防止幻读。

4.MVCC保证隔离性（I）的读-写并发

读操作不加锁，通过undo log构建的版本链找到自己应该看到的数据版本，主要适配InnoDB默认的可重复读隔离级别RR。

写的时候别人照样能读，读的时候别人照样能写，大幅度提升读写并发度。

一致性不是单独实现的，它是原子性、隔离性和持久性共同作用的结果。

数据从一个正确状态转移到另一个正确状态，中间不会出现不一致的中间态，同时满足业务的约束规则。

MyBatis Flex和MyBatis Plus的区别

Thu, 22 Jan 2026 15:00:00 +0000

MyBatis Flex和MyBatis Plus都是对原生MyBatis 框架的增强工具，都能够简化数据库的操作、提高开发效率。

两者在设计理念和功能侧重点上有以下区别：

1.MyBatis Flex除了MyBatis自身，没有任何第三方依赖，极致轻量化；而MyBatis Plus整合的功能更多（如逻辑删除、乐观锁、代码生成等），依赖也更复杂。

2.MyBatis Flex从架构上进行了优化，在SQL执行的过程中没有SQL解析环节和MyBatis拦截器，通过 AST抽象语法树构建SQL，执行链路更短，可以带来更高的性能。而MyBatis Plus大量依赖MyBatis拦截器解析SQL，执行链路更长，有一定解析开销。

3.MyBatis Flex原生支持多表关联查询，无需手写SQL，适合处理复杂的业务场景；而MyBatis Plus在多表查询时需要依赖第三方插件或者手写SQL来实现。

如何在MySQL中监控和优化慢SQL？

Tue, 20 Jan 2026 18:04:18 +0000

在MySQL中监控和优化慢SQL的核心是开启MySQL的慢查询日志，慢查询日志会把执行时间超过设定阈值的SQL语句自动记录下来，通过日志的分析与执行计划的校验实现SQL性能的精准优化。

主要步骤：

1.开启慢查询日志，设置合理的时间阈值，线上环境通常将阈值设定为1~2秒，确保执行耗时较长的慢SQL能够被精准捕获。

2.定期对慢查询日志进行分析，用MySQL自带的分析工具mysqldumpslow或Percona Toolkit里的pt-query-digest工具，对日志中的SQL进行汇总统计，定位高频出现的慢SQL。

3.对高频的慢SQL执行EXPLAIN命令分析其执行计划，检查是否走索引、扫描数据行数、是否存在文件排序等问题，再针对分析结果开展针对性优化。

几个常见的慢SQL优化方向

1.查看EXPLAIN 结果的type字段，如果值为ALL，说明当前SQL是全表扫描；如果key列为空，就说明该SQL未使用索引，需优化索引配置。

2.如果SELECT查询的字段没有包含在索引里，会触发回表查询，可以通过构建覆盖索引进行优化，把查询所需的字段都放进索引。

3.查看EXPLAIN结果的Extra字段，如果是Using filesort，说明数据库执行了手动排序；如果是Using temporary，说明用了临时表；这两种情况都可以通过为对应字段添加索引来避免。

4.避免用SELECT *查询所有字段，可以明确指定所需的字段；可以通过添加LIMIT子句控制单次查询返回的条数，从而减少数据处理压力。

MySQL中如何进行SQL调优

Mon, 19 Jan 2026 17:23:03 +0000

SQL调优的核心思路是减少磁盘I/O和避免无效计算。

主要就是先通过MySQL的慢查询日志定位慢SQL，再利用EXPLAIN分析执行计划，最后再进行针对性优化。

优化的手段主要有这几大类，分别是索引层面的优化，SQL写法层面的优化以及架构层面的优化。

索引层面的优化

合理设计联合索引，利用覆盖索引来避免回表。
注意最左匹配原则。
避免在索引列上做函数运算、隐式类型转换。
及时删除荣誉索引和重复索引。

SQL写法层面的优化

为了减少网络传输和内存占用，只对必要字段进行查询，不使用select *
为了避免全表扫描，避免%LIKE这种前缀模糊查询
连表查询时检查关联字段的字符集和排序规则是否一致，不一致会导致索引失效

架构层面的优化

对于访问频率高但是变化少的数据使用Redis缓存
对单表数据量超过2000万行或物理文件超过2G的大表进行分库分表
搭建主从数据库集群，进行读写分离，让从库分担一些查询的压力