memo：2025 年 3 月 29 日修改至此，今天有球友说美团的 offer 口头 OC 了，真的太棒了。

索引

35.🌟索引为什么能提高MySQL查询效率？

索引就像一本书的目录，能让 MySQL 快速定位数据，避免全表扫描。

它一般是 B+ 树结构，查找效率是 O(log n)，比从头到尾扫一遍数据要快得多。

除了查得快，索引还能加速排序、分组、连接等操作。

项目中最常见的做法就是通过 create index 为经常用作查询条件的字段建索引，比如：

create index idx_name on students(name);

----这部分是帮助大家理解 start，面试中可不背----

我们通过 wrap 的 agent 验证一下有没有索引的查询效率。

先上结果，有索引的查询时间是 0.007 秒，没有索引的查询时间是 0.036 秒。

创建数据库和表。

插入 10 万条数据。

然后依次执行 explain 查看没有索引和有索引时的执行计划。

----这部分是帮助大家理解 end，面试中可不背----

1. Java 面试指南（付费）收录的腾讯面经同学 23 QQ 后台技术一面面试原题：MySQL 索引，为什么用 B+树
2. Java 面试指南（付费）收录的小米面经同学 E 第二个部门 Java 后端技术一面面试原题：为什么需要索引
3. Java 面试指南（付费）收录的小公司面经同学 5 Java 后端面试原题：数据库索引讲一下，然后为什么会加快查询速度
4. Java 面试指南（付费）收录的去哪儿面经同学 1 技术二面面试原题：mysql为什么用索引
5. Java 面试指南（付费）收录的 OPPO 面经同学 1 面试原题：对MySQL索引的理解
6. Java 面试指南（付费）收录的vivo 面经同学 10 技术一面面试原题：索引，为什么使用索引更快
7. Java 面试指南（付费）收录的腾讯面经同学 27 云后台技术一面面试原题：介绍下索引？底层是啥？

memo：2025 年 3 月 30 日修改至此，之前有球友说拿到了淘天搜索的暑期实习，真的恭喜了。

36.🌟能简单说一下索引的分类吗？

从功能上分类的话，有主键索引、唯一索引、全文索引；从数据结构上分类的话，有 B+ 树索引、哈希索引；从存储内容上分类的话，有聚簇索引、非聚簇索引。

你对主键索引了解多少？

主键索引用于唯一标识表中的每条记录，其列值必须唯一且非空。创建主键时，MySQL 会自动生成对应的唯一索引。

每个表只能有一个主键索引，一般是表中的自增 id 字段。

CREATE TABLE emp6 (emp_id INT PRIMARY KEY, name VARCHAR(50));  -- 单列主键
CREATE TABLE CountryLanguage (
    CountryCode CHAR(3),
    Language VARCHAR(30),
    PRIMARY KEY (CountryCode, Language)  -- 复合主键
);

---- 这部分是帮助大家理解 start，面试中可不背 ----

如果创建表的时候没有指定主键，MySQL 的 InnoDB 存储引擎会优先选择一个非空的唯一索引作为主键；如果没有符合条件的索引，MySQL 会自动生成一个隐藏的 _rowid 列作为主键。

可以通过 show index from table_name 查看索引信息：

• Table 当前索引所属的表名。
• Non_unique 是否唯一索引，0 表示唯一索引（如主键），1 表示非唯一。
• Key_name 主键索引默认叫 PRIMARY；普通索引为自定义名。
• Seq_in_index 索引中的列顺序，在联合索引中这个字段表示第几列（第 1 个）。
• Column_name 当前索引中包含的字段名。
• Collation A 表示升序（Ascend）；D 表示降序。
• Cardinality 索引的基数，即不重复的索引值的数量。越高说明区分度越好（影响优化器是否用此索引）。
• Sub_part 前缀索引的长度。
• Packed 是否压缩存储索引；一般不用，默认为 NULL。
• Null 字段是否允许为 NULL；主键字段不允许为 NULL。
• Index_type 索引底层结构，InnoDB 默认是 B+ 树（BTREE）。
• Comment 索引的注释。
• Visible 是否可见；MySQL 8.0+ 可隐藏索引。

---- 这部分是帮助大家理解 end，面试中可不背 ----

唯一索引和主键索引有什么区别？

主键索引=唯一索引+非空。每个表只能有一个主键索引，但可以有多个唯一索引。

-- 在 email 列上添加唯一索引
CREATE TABLE users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(50) NOT NULL,
    email VARCHAR(100) NOT NULL,
    UNIQUE KEY uk_email (email)  -- 唯一索引
);

-- 复合唯一索引（保证 user_id 和 role 组合唯一）
CREATE TABLE user_roles (
    user_id INT NOT NULL,
    role VARCHAR(20) NOT NULL,
    UNIQUE KEY uk_user_role (user_id, role)
);

主键索引不允许插入 NULL 值，尝试插入 NULL 会报错；唯一索引允许插入多个 NULL 值。

unique key 和 unique index 有什么区别？

创建唯一键时，MySQL 会自动生成一个同名的唯一索引；反之，创建唯一索引也会隐式添加唯一性约束。

可通过 UNIQUE KEY uk_name 定义或者 CONSTRAINT uk_name UNIQUE 定义唯一键。

CREATE TABLE users (
    id INT PRIMARY KEY,
    email VARCHAR(100),
    -- 显式命名唯一键
    CONSTRAINT uk_email UNIQUE (email)
);

CREATE TABLE users3 (
     id INT PRIMARY KEY,
    email VARCHAR(100),
    UNIQUE KEY uk_email (email)  -- 唯一索引
);

可通过 CREATE UNIQUE INDEX 创建唯一索引。

CREATE TABLE users (
    id INT PRIMARY KEY,
    email VARCHAR(100)
);

-- 手动创建唯一索引
CREATE UNIQUE INDEX uk_email ON users(email);

通过 SHOW CREATE TABLE table_name 查看表结构时，结果都是一样的。

普通索引和唯一索引有什么区别？

普通索引仅用于加速查询，不限制字段值的唯一性；适用于高频写入的字段、范围查询的字段。

-- 日志时间戳允许重复，无需唯一性检查
CREATE INDEX idx_log_time ON access_logs(access_time);

-- 订单状态允许重复，但需频繁按状态过滤数据
CREATE INDEX idx_order_status ON orders(status);

唯一索引强制字段值的唯一性，插入或更新时会触发唯一性检查；适用于业务唯一性约束的字段、防止数据重复插入的字段。

-- 用户邮箱必须唯一
CREATE UNIQUE INDEX uk_email ON users(email);

-- 确保同一用户对同一商品只能有一条未支付订单
CREATE UNIQUE INDEX uk_user_product ON orders(user_id, product_id) WHERE status = 'unpaid';

memo：2025 年 3 月 31 日修改至此，今天有球友说，拿到了淘天暑期实习的 offer，并且再次强调背面渣逆袭的重要性，哈哈。

你对全文索引了解多少？

全文索引是 MySQL 一种优化文本数据检索的特殊类型索引，适用于 CHAR、VARCHAR 和 TEXT 等字段。

MySQL 5.7 及以上版本内置了 ngram 解析器，可处理中文、日文和韩文等分词。

建表时通过 FULLTEXT (title, body) 来定义。通过 MATCH(col1, col2) AGAINST('keyword') 进行检索，默认按照降序返回结果，支持布尔模式查询。

• + 表示必须包含；
• - 表示排除；
• * 表示通配符；

-- 建表时创建全文索引（支持中文）
CREATE TABLE articles (
    id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    title VARCHAR(200),
    content TEXT,
    FULLTEXT(title, content) WITH PARSER ngram
) ENGINE=InnoDB;

-- 使用布尔模式查询
SELECT * FROM articles 
WHERE MATCH(title, content) AGAINST('+MySQL -Oracle' IN BOOLEAN MODE);

底层使用倒排索引将字段中的文本内容进行分词，然后建立一个倒排表。性能比 LIKE '%keyword%' 高很多。

---- 这部分是帮助大家理解 start，面试中可不背 ----

倒排索引通过一个辅助表存储单词与单词自身在一个或多个文档中所在位置之间的映射，通常采用关联数组实现。

有两种表现形式：inverted file index（{单词，单词所在文档的ID}）和full inverted index（{单词，(单词所在文档的ID，在具体文档中的位置)}）

比如有这样一个文档：

 DocumentId  Text  
1          Pease porridge hot, pease porridge cold  
2          Pease porridge in the pot  
3          Nine days old  
4          Some like it hot, some like it cold  
5          Some like it in the pot  
6          Nine days old

inverted file index 的关联数组存储形式为：

days → 3,6  
old → 3,6  
pease → 1,2  
porridge → 1,2  
...

full inverted index 更加详细：

days → (3:5),(6:5)  
old → (3:11),(6:11)  
pease → (1:1),(1:7),(2:1)  
porridge → (1:7),(2:7)  
...

full inverted index 不仅存储了文档 ID，还存储了单词在文档中的具体位置。

InnoDB 采用的是 full inverted index 的方式实现全文索引。

如果需要处理中文分词的话，一定要记得加上 WITH PARSER ngram，否则可能查不出来数据。

不过，对于复杂的中文场景，建议使用 Elasticsearch 等专业搜索引擎替代，技术派项目中就用了这种方案。

---- 这部分是帮助大家理解 end，面试中可不背 ----

memo：2025 年 4 月 1 日修改至此，今天有球友说，拿到了美团的实习 offer，真的太棒了，18 号一面、25 号二面、30 号 OC，4 月 1 发邮件 offer，节奏拉满了

1. Java 面试指南（付费）收录的科大讯飞非凡计划研发类面经原题：聊聊 MySQL 的索引
2. Java 面试指南（付费）收录的腾讯面经同学 23 QQ 后台技术一面面试原题：MySQL 索引，为什么用 B+树
3. Java 面试指南（付费）收录的携程面经同学 10 Java 暑期实习一面面试原题：讲一讲 MySQL 的索引，如何优化 SQL？
4. Java 面试指南（付费）收录的阿里面经同学 5 阿里妈妈 Java 后端技术一面面试原题：索引的分类，创建索引的最佳实践
5. Java 面试指南（付费）收录的 360 面经同学 3 Java 后端技术一面面试原题：mysql 的索引用过哪些
6. Java 面试指南（付费）收录的用友面试原题：索引是什么？有哪些索引
7. Java 面试指南（付费）收录的作业帮面经同学 1 Java 后端一面面试原题：普通索引的叶子节点存储的是什么
8. Java 面试指南（付费）收录的作业帮面经同学 1 Java 后端一面面试原题：innodb底层有哪些数据结构
9. Java 面试指南（付费）收录的比亚迪面经同学 12 Java 技术面试原题：索引有哪些，区别是什么

37.🌟创建索引有哪些注意点？

第一，选择合适的字段

• 比如说频繁出现在 WHERE、JOIN、ORDER BY、GROUP BY 中的字段。
• 优先选择区分度高的字段，比如用户 ID、手机号等唯一值多的，而不是性别、状态等区分度极低的字段，如果真的需要，可以考虑联合索引。

第二，要控制索引的数量，避免过度索引，每个索引都要占用存储空间，单表的索引数量不建议超过 5 个。

要定期通过 SHOW INDEX FROM table_name 查看索引的使用情况，删除不必要的索引。比如说已经有联合索引 (a, b)，单索引（a）就是冗余的。

第三，联合索引的时候要遵循最左前缀原则，即在查询条件中使用联合索引的第一个字段，才能充分利用索引。

比如说联合索引 (A, B, C) 可支持 A、A+B、A+B+C 的查询，但无法支持 B 或 C 的单独查询。

区分度高的字段放在左侧，等值查询的字段优先于范围查询的字段。例如 WHERE A=1 AND B>10 AND C=2，优先 (A, C, B)。

如果联合索引包含查询的所需字段，还可以避免回表，提高查询效率。

1. Java 面试指南（付费）收录的用友金融一面原题：索引的作用，加索引需要注意什么
2. Java 面试指南（付费）收录的京东同学 10 后端实习一面的原题：查询和更新都频繁的字段是否适合创建索引，为什么
3. Java 面试指南（付费）收录的小米春招同学 K 一面面试原题：索引怎么设计才是最好的
4. Java 面试指南（付费）收录的京东面经同学 1 Java 技术一面面试原题：MySQL 索引结构，建立索引的策略
5. Java 面试指南（付费）收录的阿里面经同学 5 阿里妈妈 Java 后端技术一面面试原题：索引的分类，创建索引的最佳实践
6. Java 面试指南（付费）收录的oppo 面经同学 8 后端开发秋招一面面试原题：建索引的时候应该注意什么
7. Java 面试指南（付费）收录的京东面经同学 5 Java 后端技术一面面试原题：建立索引考虑哪些问题

38.🌟索引哪些情况下会失效呢？

简版：比如索引列使用了函数、使用了通配符开头的模糊查询、联合索引不满足最左前缀原则，或者使用 or 的时候部分字段无索引等。

第一，对索引列使用函数或表达式会导致索引失效。

-- 索引失效
SELECT * FROM users WHERE YEAR(create_time) = 2023;
SELECT * FROM products WHERE price*2 > 100;

-- 优化方案（使用范围查询）
SELECT * FROM users WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31';
SELECT * FROM products WHERE price > 50;

第二，LIKE 模糊查询以通配符开头会导致索引失效。

-- 索引失效
SELECT * FROM articles WHERE title LIKE '%数据库%';

-- 可以使用索引（但范围有限）
SELECT * FROM articles WHERE title LIKE '数据库%';

-- 解决方案：考虑全文索引或搜索引擎
SELECT * FROM articles WHERE MATCH(title) AGAINST('数据库');

第三，联合索引违反了最左前缀原则，索引会失效。

-- 假设有联合索引 (a, b, c)
SELECT * FROM table WHERE b = 2 AND c = 3;  -- 索引失效
SELECT * FROM table WHERE a = 1 AND c = 3;  -- 只使用a列索引

-- 正确使用联合索引
SELECT * FROM table WHERE a = 1 AND b = 2 AND c = 3;

• 联合索引，但 WHERE 不满足最左前缀原则，索引无法起效。例如：SELECT * FROM table WHERE column2 = 2，联合索引为 (column1, column2)。

---- 这部分是帮助大家理解 start，面试中可不背 ----

第四，使用 OR 连接非索引列条件，会导致索引失效。

-- 假设name有索引但age没有
SELECT * FROM users WHERE name = '张三' OR age = 25;  -- 全表扫描

-- 优化方案1：使用UNION ALL
SELECT * FROM users WHERE name = '张三'
UNION ALL
SELECT * FROM users WHERE age = 25 AND name != '张三';

-- 优化方案2：考虑为age添加索引

第五，使用 != 或 <> 不等值查询会导致索引失效。

SELECT * FROM user WHERE status != 1;  -- 若大部分行 `status=1`，可能全表扫描

-- 优化方案：使用范围查询
SELECT * FROM user WHERE status < 1 OR status > 1;

---- 这部分是帮助大家理解 end，面试中可不背 ----

什么情况下模糊查询不走索引？

模糊查询主要使用 LIKE 语句，结合通配符来实现。

%（代表任意多个字符）和 _（代表单个字符）

SELECT * FROM table WHERE column LIKE '%xxx%';

这个查询会返回所有 column 列中包含 xxx 的记录。

但是，如果模糊查询的通配符 % 出现在搜索字符串的开始位置，如 LIKE '%xxx'，MySQL 将无法使用索引，因为数据库必须扫描全表以匹配任意位置的字符串。

1. Java 面试指南（付费）收录的字节跳动面经同学 1 Java 后端技术一面面试原题：where b =5 是否一定会命中索引？（索引失效场景）
2. Java 面试指南（付费）收录的京东面经同学 1 Java 技术一面面试原题：索引失效的情况
3. Java 面试指南（付费）收录的小公司面经合集同学 1 Java 后端面试原题：编写 SQL 语句哪些情况会导致索引失效？
4. Java 面试指南（付费）收录的比亚迪面经同学 12 Java 技术面试原题：索引失效场景
5. Java 面试指南（付费）收录的 OPPO 面经同学 1 面试原题：什么情况下索引失效？
6. Java 面试指南（付费）收录的京东面经同学 5 Java 后端技术一面面试原题：索引失效情况
7. Java 面试指南（付费）收录的理想汽车面经同学 2 一面面试原题：什么操作会导致索引失效？

39.索引不适合哪些场景呢？

第一，区分度低的列，可以和其他高区分度的列组成联合索引。

第二，频繁更新的列，索引会增加更新的成本。

第三，TEXT、BLOB 等大对象类型的字段，可以使用前缀索引、全文索引替代。

第四，当表的数据量很小的时候，不超过 1000 行，全表扫描可能比使用索引更快。

---- 这部分是帮助大家理解 start，面试中可不背 ----

为了验证第四条，我们创建了一个小表，然后分别执行全表扫描和索引查询。

得出的结论的确是这样的，全表扫描更快一些。

原因时当数据量很小时，全表扫描的成本很低，因为所有的数据可能都加载到内存中了，使用索引反而需要先查找索引，再通过索引去找到实际的数据行，增加了额外的 I/O 寻址时间。

---- 这部分是帮助大家理解 end，面试中可不背 ----

性别字段要建立索引吗？

性别字段不适合建立单独索引。因为性别字段的区分度很低。

如果性别字段确实经常用于查询条件，数据规模也比较大，可以将性别字段作为联合索引的一部分，与区分度高的字段一起，效果会好很多。

什么是区分度？

区分度是衡量一个字段在 MySQL 表中唯一值的比例。

区分度 = 字段的唯一值数量 / 字段的总记录数；越接近 1，就越适合作为索引。因为索引可以更有效地缩小查询范围。

例如，一个表中有 1000 条记录，其中性别字段只有两个值（男、女），那么性别字段的区分度只有 0.002，就不适合建立索引。

可以通过 COUNT(DISTINCT column_name) 和 COUNT(*) 的比值来计算字段的区分度。例如：

SELECT 
    COUNT(DISTINCT gender) / COUNT(*) AS gender_selectivity
FROM 
    users;

什么样的字段适合加索引？

一句话回答：

一般来说，主键、唯一键、以及经常作为查询条件的字段最适合加索引。除此之外，字段的区分度要高，这样索引才能起到过滤作用；如果字段经常用于表连接、排序或分组，也建议加索引。同时如果多个字段经常一起出现在查询条件中，也可以建立联合索引来提升性能。

---- 这部分是帮助大家理解 start，面试中可不背 ----

查询条件中的高频字段，比如说WHERE子句中频繁用于等值查询、范围查询或者 IN 列表的字段。

SELECT * FROM orders WHERE status = 'PAID' AND create_time > '2023-01-01';
-- 若`status`和`create_time`常组合查询，建联合索引`(status, create_time)`

多表连接时的关联字段，比如说 user.id 和 order.user_id。

SELECT * FROM user u JOIN order o ON u.id = o.user_id;  -- `user_id`需索引

参与排序或者分组的字段，可以直接利用索引的有序性，避免文件排序。

SELECT * FROM product ORDER BY price DESC;       -- 单字段排序
SELECT category, COUNT(*) FROM product GROUP BY category;  -- 分组统计

需要利用覆盖索引的字段，可以避免回表操作。

-- 创建联合索引`(user_id, create_time)`
SELECT user_id, create_time FROM orders WHERE user_id = 100;  -- 覆盖索引生效

---- 这部分是帮助大家理解 end，面试中可不背 ----

1. Java 面试指南（付费）收录的字节跳动面经同学 1 技术二面面试原题：性别字段要建立索引吗？为什么？什么是区分度？MySQL查看字段区分度的命令？
2. Java 面试指南（付费）收录的快手同学 2 一面面试原题：什么样的字段适合加索引？什么不适合？

40.索引是不是建的越多越好？

索引不是越多越好。虽然索引可以加快查询，但也会带来写入变慢、占用更多存储空间、甚至让优化器选错索引的风险。

---- 这部分是帮助大家理解 start，面试中可不背 ----

每次数据写入（INSERT/UPDATE/DELETE）时，MySQL 都需同步更新所有相关索引，索引越多，维护成本越高。

假如某表有 10 个索引，插入一行数据需更新 10 个 B+树结构，导致写入延迟增加 5~10 倍。

假如某表数据量 100GB，若建 5 个索引，总存储可能达到 200GB+。

索引过多时，优化器需评估更多可能的执行路径，可能导致选择困难症，优化器也会选错索引。

再比如说，已有联合索引 (A, B, C)，再单独建 (A) 或 (A, B) 索引即为冗余。

单表索引数量建议不超过 5 个，MySQL 官方建议单表索引总字段数 ≤ 表字段数的 30%。

---- 这部分是帮助大家理解 end，面试中可不背 ----

说说索引优化的思路？

一句话回答：

先通过慢查询日志找出性能瓶颈，然后用 EXPLAIN 分析执行计划，判断是否走了索引、是否回表、是否排序。接着根据字段特性设计合适的索引，如选择区分度高的字段，使用联合索引和覆盖索引，避免索引失效的写法，最后通过实测来验证优化效果。

1. Java 面试指南（付费）收录的比亚迪面经同学 12 Java 技术面试原题：索引优化的思路

memo：2025 年 4 月 2 日修改至此，今天有球友说，拿到了百度的实习 offer，仅用了一个月的时间，可太强了。

41.🌟为什么 InnoDB 要使用 B+树作为索引？

一句话总结：

因为 B+ 树是一种高度平衡的多路查找树，能有效降低磁盘的 IO 次数，并且支持有序遍历和范围查询。

查询性能非常高，其结构也适合 MySQL 按照页为单位在磁盘上存储。

像其他选项，比如说哈希表不支持范围查询，二叉树层级太深，B 树又不方便范围扫描，所以最终选择了 B+ 树。

再换一种回答：

• 相比哈希表：B+ 树支持范围查询和排序
• 相比二叉树和红黑树：B+ 树更“矮胖”，层级更少，磁盘 IO 次数更少
• 相比 B 树：B+ 树的非叶子节点只存储键值，叶子节点存储数据并通过链表连接，支持范围查询

另外一种回答版本：

B+树是一种自平衡的多路查找树，和红黑树、二叉平衡树不同，B+树的每个节点可以有 m 个子节点，而红黑树和二叉平衡树都只有 2 个。

另外，和 B 树不同，B+树的非叶子节点只存储键值，不存储数据，而叶子节点存储了所有的数据，并且构成了一个有序链表。

这样做的好处是，非叶子节点上由于没有存储数据，就可以存储更多的键值对，再加上叶子节点构成了一个有序链表，范围查询时就可以直接通过叶子节点间的指针顺序访问整个查询范围内的所有记录，而无需对树进行多次遍历。查询的效率比 B 树更高。

1. 推荐阅读：终于把 B 树搞明白了
2. 推荐阅读：一篇文章讲透 MySQL 为什么要用 B+树实现索引

---- 这部分是帮助大家理解 start，面试中可不背 ----

先说说 B 树。

B 树是一种自平衡的多路查找树，和红黑树、二叉平衡树不同，B 树的每个节点可以有 m 个子节点，而红黑树和二叉平衡树都只有 2 个。

换句话说，红黑树、二叉平衡树是细高个，而 B 树是矮胖子。

再来说说内存和磁盘的 IO 读写。

为了提高读写效率，从磁盘往内存中读数据的时候，一次会读取至少一页的数据，如果不满一页，会再多读点。

比如说查询只需要读取 2KB 的数据，但 MySQL 实际上会读取 4KB 的数据，以装满整页。页是 MySQL 进行内存和磁盘交互的最小逻辑单元。

再比如说需要读取 5KB 的数据，实际上 MySQL 会读取 8KB 的数据，刚好两页。

因为读的次数越多，效率就越低。就好比我们在工地上搬砖，一次搬 10 块砖肯定比一次搬 1 块砖的效率要高，反正我每次都搬 10 块（😁）。

对于红黑树、二叉平衡树这种细高个来说，每次搬的砖少，因为力气不够嘛，那来回跑的次数就越多。

通常 B+ 树高度为 3-4 层即可支持 TB 级数据，而每次查询只需 2-4 次磁盘 I/O，远低于二叉树或红黑树的 O(log2N) 复杂度

树越高，意味着查找数据时就需要更多的磁盘 IO，因为每一层都可能需要从磁盘加载新的节点。

B 树的节点通常与页的大小对齐，这样每次从磁盘加载一个节点时，正好就是一页的大小。

B 树的一个节点通常包括三个部分：

• 键值：即表中的主键
• 指针：存储子节点的信息
• 数据：除主键外的行数据

正所谓“祸兮福所倚，福兮祸所伏”，因为 B 树的每个节点上都存储了数据，就导致每个节点能存储的键值和指针变少了，因为每一个节点的大小是固定的，对吧？

于是 B+树就来了，B+树的非叶子节点只存储键值，不存储数据，而叶子节点会存储所有的行数据，并且构成一个有序链表。

这样做的好处是，非叶子节点由于没有存储数据，就可以存储更多的键值对，树就变得更加矮胖了，于是就更有劲了，每次搬的砖也就更多了（😂）。

相比 B 树，B+ 树的非叶子节点可容纳的键值更多，一个 16KB 的节点可存储约 1200 个键值，大幅降低树的高度。

由此一来，查找数据进行的磁盘 IO 就更少了，查询的效率也就更高了。

再加上叶子节点构成了一个有序链表，范围查询时就可以直接通过叶子节点间的指针顺序访问整个查询范围内的所有记录，而无需对树进行多次遍历。

B 树就做不到这一点。

---- 这部分是帮助大家理解 end，面试中可不背 ----

B+树的叶子节点是单向链表还是双向链表？如果从大值向小值检索，如何操作？

B+树的叶子节点是通过双向链表连接的，这样可以方便范围查询和反向遍历。

• 当执行范围查询时，可以从范围的开始点或结束点开始，向前或向后遍历。
• 在需要对数据进行逆序处理时，双向链表非常有用。

如果需要在 B+树中从大值向小值进行检索，可以先定位到最右侧节点，找到包含最大值的叶子节点。从根节点开始向右遍历树的方式实现。

定位到最右侧的叶子节点后，再利用叶节点间的双向链表向左遍历就好了。

为什么 MongoDB 的索引用 B树，而 MySQL 用 B+ 树？

MongoDB 通常以 JSON 格式存储文档，查询以单键查询（如 find({_id: 123})）为主。B 树的“节点既存键又存数据”的特性允许查询在非叶子节点提前终止，从而减少 I/O 次数。

MySQL 的查询通常涉及范围（WHERE id > 100）、排序（ORDER BY）、连接（JOIN）等操作。B+ 树的叶子节点是链表结构，天然支持顺序遍历，无需回溯至根节点或中序遍历，效率远高于 B 树。

---- 这部分是帮助大家理解 start，面试中可不背 ----

推荐阅读：为什么 MongoDB 索引用 B树，而 MySQL 用 B+ 树？

---- 这部分是帮助大家理解 end，面试中可不背 ----

1. Java 面试指南（付费）收录的字节跳动商业化一面的原题：说说 B+树，为什么 3 层容纳 2000W 条，为什么 2000w 条数据查的快
2. Java 面试指南（付费）收录的国企面试原题：说说 MySQL 的底层数据结构，B 树和 B+树的区别
3. Java 面试指南（付费）收录的腾讯面经同学 22 暑期实习一面面试原题：MySQL 为什么选用 B+树
4. Java 面试指南（付费）收录的小米面经同学 E 第二个部门 Java 后端技术一面面试原题：说一说 mysql 索引的底层机制
5. Java 面试指南（付费）收录的京东面经同学 1 Java 技术一面面试原题：MySQL 索引结构，建立索引的策略
6. Java 面试指南（付费）收录的腾讯云智面经同学 16 一面面试原题：MySQL 索引结构，为什么用 B+树？
7. Java 面试指南（付费）收录的小公司面经同学 5 Java 后端面试原题：数据库索引讲一下，然后为什么会加快查询速度，我讲到了 B+树，然后问了 B 数与 B+树区别
8. Java 面试指南（付费）收录的百度面经同学 1 文心一言 25 实习 Java 后端面试原题：B+树的页是单向链表还是双向链表？如果从大值向小值检索，如何操作？
9. Java 面试指南（付费）收录的得物面经同学 1 面试原题：项目索引，MySQL索引，mongoDB为什么用的B树，二者比较
10. Java 面试指南（付费）收录的oppo 面经同学 8 后端开发秋招一面面试原题：Mysql索引的数据结构，为什么选择这样的数据结构
11. Java 面试指南（付费）收录的京东面经同学 8 面试原题：索引
12. Java 面试指南（付费）收录的美团同学 9 一面面试原题：B+树？
13. Java 面试指南（付费）收录的美团面经同学 15 点评后端技术面试原题：索引的数据结构
14. Java 面试指南（付费）收录的得物面经同学 9 面试题目原题：B+树了解吗？底层呢？为什么这么用？
15. Java 面试指南（付费）收录的滴滴面经同学 3 网约车后端开发一面原题：MySQL索引原理，B+树更扁 有什么好处

memo：2025 年 4 月 3 日修改至此，今天有球友说，拿到了美团的实习 offer，恭喜啊。

42.🌟一棵B+树能存储多少条数据呢？

一句话回复：

一棵 B+ 树能存多少数据，取决于它的分支因子和高度。在 InnoDB 中，页的默认大小为 16KB，当主键为 bigint 时，3 层 B+ 树通常可以存储约 2000 万条数据。

---- 这部分是帮助大家理解 start，面试中可不背 ----

先来看一下计算公式：

最大记录数 = (分支因子)^(树高度-1) × 叶子节点容量

再来看一下关键参数：

①、页大小，默认 16KB

②、主键大小，假设是 bigint 类型，那么它的大小就是 8 个字节。

③、页指针大小，InnoDB 源码中设置为 6 字节，4 字节页号 + 2 字节页内偏移。

所以非叶子节点可以存储 16384/14(键值+指针)=1170 个这样的单元。

当层高为 2 时，根节点可以存储 1170 个指针，指向 1170 个叶子节点，所以总数据量为 1170×16 =18720 条。

当层高为 3 时，根节点指向 1170 个非叶子节点，每个非叶子节点再指向 1170 个叶子节点，所以总数据量为 1170×1170×16≈21,902,400 条（约2,190万条）记录。

推荐阅读：清幽之地：InnoDB 一棵 B+树可以存放多少行数据？

---- 这部分是帮助大家理解 end，面试中可不背 ----

现在有一张表 2kw 数据，我这个 b+树的高度有几层？

对于 2KW 条数据来说，B+树的高度为 3 层就够了。

推荐阅读：Innodb 引擎中 B+树一般有几层？能容纳多少数据量？

每个叶子节点能存放多少条数据？

如果单行数据大小为 1KB，那么每页可存储约 16 行（16KB/1KB）数据。

---- 这部分是帮助大家理解 start，面试中可不背 ----

假设有这样一个表结构：

CREATE TABLE `user` (
  `id` BIGINT PRIMARY KEY,        -- 8字节
  `name` VARCHAR(255) NOT NULL,   -- 实际长度50字节（UTF8MB4，每个字符最多4字节）
  `age` TINYINT,                  -- 1字节
  `email` VARCHAR(255)            -- 实际长度30字节，可为NULL
) ROW_FORMAT=COMPACT;

那么一行数据的大小为：8 + 50 + 1 + 30 = 89 字节。

行格式的开销为：行头 5 字节+指针 6 字节+可变长度字段开销 2 字节（name 和 email 各占 1 字节）+ NULL 位图 1 字节 = 14 字节。

所以每行数据的实际大小为：89 + 14 = 103 字节。

每页大小默认为 16KB，那么每页最多可以存储 16384 / 103 ≈ 158 行数据。

---- 这部分是帮助大家理解 end，面试中可不背 ----

1. Java 面试指南（付费）收录的字节跳动商业化一面的原题：说说 B+树，为什么 3 层容纳 2000W 条，为什么 2000w 条数据查的快
2. Java 面试指南（付费）收录的奇安信面经同学 1 Java 技术一面面试原题：innodb 使用数据页存储数据？默认数据页大小 16K，我现在有一张表，有 2kw 数据，我这个 b+树的高度有几层？
3. Java 面试指南（付费）收录的美团面经同学 18 成都到家面试原题：一张表最多存多少数据（我答得2kw，根据b+树的三层高度计算）
4. Java 面试指南（付费）收录的得物面经同学 1 面试原题：MySQL B+树的度数越大越好吗，一般设多少
5. Java 面试指南（付费）收录的腾讯面经同学 29 Java 后端一面原题：InnoDB中一个三层的B+树能存多少数据？每个叶子节点能存放多少条数据？

memo：2025 年 4 月 4 日修改至此，今天有球友问，有没有英文版的面渣逆袭，他人在国外留学，国外也开始卷八股了吗，真的离谱。

43.索引为什么用 B+树不用普通二叉树？

普通二叉树的每个节点最多有两个子节点。当数据按顺序递增插入时，二叉树会退化成链表，导致树的高度等于数据量。

此时查找 id=7 就需要 7 次 I/O 操作，相当于全表扫描。而 B+ 树作为多叉平衡树，能将数亿级的数据量控制在 3-4 层的树高，能极大减少磁盘的 I/O 次数。

为什么不用平衡二叉树呢？

平衡二叉树虽然解决了普通二叉树的退化问题，但每个节点最多只有两个子节点的问题依然存在。

1. Java 面试指南（付费）收录的百度面经同学 1 文心一言 25 实习 Java 后端面试原题：MySQL 索引为什么使用 B+树而不是用别的数据结构？
2. Java 面试指南（付费）收录的腾讯面经同学 27 云后台技术一面面试原题：为什么不用二叉树？为什么不用AVL树？

44.🌟为什么用 B+ 树而不用 B 树呢？

B+ 树相比 B 树有 3 个显著优势：

第一，B 树的每个节点既存储键值，又存储数据和指针，导致单节点存储的键值数量较少。

一个 16KB 的 InnoDB 页，如果数据较大，B 树的非叶子节点只能容纳几十个键值，而 B+ 树的非叶子节点可以容纳上千个键值。

第二，B 树的范围查询需要通过中序遍历逐层回溯；而 B+ 树的叶子节点通过双向链表顺序连接，范围查询只需定位起始点后顺序遍历链表即可，没有回溯开销。

第三，B 树的数据可能存储在任意节点，假如目标数据恰好位于根节点或上层节点，查询仅需 1-2 次 I/O；但如果数据位于底层节点，则需多次 I/O，导致查询时间波动较大。

而 B+ 树的所有数据都存储在叶子节点，查询路径的长度是固定的，时间稳定为 O(logN)，对 MySQL 在高并发场景下的稳定性至关重要。

想要了解 B 树和 B+树的更多区别，推荐阅读：

• GitHub：B 树和 B+树详解
• 思否：面试官问你 B 树和 B+树，就把这篇文章丢给他
• 极客时间：为什么用 B+树来做索引？
• 一颗剽悍的种子：用 16 张图就给你讲明白 MySQL 为什么要用 B+树做索引

B+树的时间复杂度是多少？

O(logN)。

树的高度 h 为：

$$ h = \lceil \log_m N \rceil $$

其中 N 是数据总量，m 是阶数。每层需要做一次二分查找，复杂度为 $O(\log m)$。

总复杂度为：

$$ O(\log_m N \cdot \log m) = O(\log N) $$

为什么用 B+树不用跳表呢？

跳表本质上还是链表结构，只不过把某些节点抽到上层做了索引。

一条数据一个节点，如果需要存放 2000 万条数据，且每次查询都要能达到二分查找的效果，那么跳表的高度大约为 24 层（2 的 24 次方）。

在最坏的情况下，这 24 层数据分散在不同的数据页，查找一次数据就需要 24 次磁盘 I/O。

而 2000 万条数据在 B+树中只需要 3 层就可以了。

B+树的范围查找怎么做的？

一句话回答：

先通过索引路径定位到第一个满足条件的叶子节点，然后顺着叶子节点之间的链表向右/向左扫描，直到超过范围。

详细版：

B+ 树索引的范围查找主要依赖叶子节点之间的双向链表来完成。

第一步，从 B+ 树的根节点开始，通过索引键值逐层向下，找到第一个满足条件的叶子节点。

第二步，利用叶子节点之间的双向链表，从起始节点开始，依次向后遍历每个节点。当索引值超过查询范围，或者遍历到链表末尾时，终止查询。

---- 这部分是帮助大家理解 start，面试中可不背 ----

比如说在下面这棵 B+ 树上查找 45。

第一步，从根节点开始，因为比 25 大，所以从右子树开始。因为 45 比 35大，所以和右边的索引比较，右侧的索引也是 45，所以继续往右子树查找。

第二步，从叶子节点 45 开始，依次遍历，找到 45。

---- 这部分是帮助大家理解 end，面试中可不背 ----

了解快排吗？

快速排序使用分治法将一个序列分为较小和较大的 2 个子序列，然后递归排序两个子序列，由东尼·霍尔在 1960 年提出。

其核心思想是：

1. 选择一个基准值。
2. 将数组分为两部分，左边小于基准值，右边大于或等于基准值。
3. 对左右两部分递归排序，最终合并。

public static void quickSort(int[] arr, int low, int high) {
    if (low < high) {
        int pivotIndex = partition(arr, low, high);
        quickSort(arr, low, pivotIndex - 1);
        quickSort(arr, pivotIndex + 1, high);
    }
}
private static int partition(int[] arr, int low, int high) {
    int pivot = arr[high];
    int i = low - 1;
    for (int j = low; j < high; j++) {
        if (arr[j] <= pivot) {
            i++;
            swap(arr, i, j);
        }
    }
    swap(arr, i + 1, high);
    return i + 1;
}
private static void swap(int[] arr, int i, int j) {
    int temp = arr[i];
    arr[i] = arr[j];
    arr[j] = temp;
}

推荐链接：快速排序

1. Java 面试指南（付费）收录的支付宝面经同学 2 春招技术一面面试原题：聚簇索引和非聚簇索引的区别？B+树叶子节点除了存数据还有什么？
2. Java 面试指南（付费）收录的奇安信面经同学 1 Java 技术一面面试原题：b 树和 b+树有什么区别
3. Java 面试指南（付费）收录的百度面经同学 1 文心一言 25 实习 Java 后端面试原题：MySQL 索引为什么使用 B+树而不是用别的数据结构？
4. Java 面试指南（付费）收录的字节跳动面经同学 8 Java 后端实习一面面试原题：mysql b+树和b树的区别
5. Java 面试指南（付费）收录的作业帮面经同学 1 Java 后端一面面试原题：B+树有哪些优点
6. Java 面试指南（付费）收录的同学 1 贝壳找房后端技术一面面试原题：为什么用b+树不用b树
7. Java 面试指南（付费）收录的阿里系面经同学 19 饿了么面试原题：索引为什么用B+树不用B树 时间复杂度深究 b+树 快速排序...

45.B+树索引和 Hash 索引有什么区别？

简版回答：

B+ 树索引支持范围查询、有序扫描，是 InnoDB 的默认索引结构。

Hash 索引只支持等值查找，速度快但功能弱，常见于 Memory 引擎。

稍微详细一点的回答：

B+ 树索引是一种平衡多路搜索树，所有数据存储在叶子节点上，非叶子节点仅存储索引键。叶子节点通过指针连接形成有序链表，天然支持排序。

并且支持范围查询、模糊查询，是 InnoDB 默认的索引结构。

Hash 索引基于哈希函数将键值映射到固定长度的哈希值，通过哈希值定位数据存储的位置。

完全无序，只支持等值查询，常见于 Memory 引擎。

---- 这部分是帮助大家理解 start，面试中可不背 ----

因为 B+ 树是 InnoDB 的默认索引类型，所以创建 B+ 树的时候不需要指定索引类型。

CREATE TABLE example_btree (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(255),
    INDEX name_index (name)
) ENGINE=InnoDB;

可以通过 UNIQUE HASH 创建哈希索引：

CREATE TABLE example_hash (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(255),
    UNIQUE HASH (name)
) ENGINE=MEMORY;

InnoDB 并不提供直接创建哈希索引的选项，因为 B+ 树索引能够很好地支持范围查询和等值查询，满足了大多数数据库操作的需要。

不过，InnoDB 内部使用了一种名为“自适应哈希索引”（Adaptive Hash Index, AHI）的技术，当某些索引值频繁访问时，InnoDB 会在 B+ 树基础上自动创建哈希索引，兼具两者的优点。

可通过 SHOW VARIABLES LIKE 'innodb_adaptive_hash_index'; 查看自适应哈希索引的状态。

如果返回的值是 ON，说明自适应哈希索引是开启的。

---- 这部分是帮助大家理解 end，面试中可不背 ----

1. Java 面试指南（付费）收录的作业帮面经同学 1 Java 后端一面面试原题：为什么不用hash索引

46.🌟聚族索引和非聚族索引有什么区别？

聚簇索引的叶子节点存储了完整的数据行，数据和索引是在一起的。InnoDB 的主键索引就是聚簇索引，叶子节点不仅存储了主键值，还存储了其他列的值，因此按照主键进行查询的速度会非常快。

每个表只能有一个聚簇索引，通常由主键定义。如果没有显式指定主键，InnoDB 会隐式创建一个隐藏的主键索引 row_id。

非聚簇索引的叶子节点只包含了主键值，需要通过回表按照主键去聚簇索引查找其他列的值，唯一索引、普通索引等非主键索引都是非聚簇索引。

每个表都可以创建多个非聚簇索引，如果不想回表的话，可以通过覆盖索引把要查询的字段也放到索引中。

---- 这部分是帮助大家理解 start，面试中可不背 ----

一张表只能有一个聚簇索引。

CREATE TABLE user (
  id INT PRIMARY KEY,
  name VARCHAR(100),
  age INT
);

主键 id 是聚簇索引，B+ 树的叶子节点直接存储了 (id, name, age)。

一张表可以有多个非聚簇索引。

CREATE INDEX idx_name ON user(name);
CREATE INDEX idx_age ON user(age);

idx_name 是非聚簇索引，叶子节点存的是 name -> id，查整行数据要回表。

idx_age 也是非聚簇索引，叶子节点存的是 age -> id，查整行数据也要回表。

想要了解更多聚簇索引和非聚簇索引，推荐阅读：

• 磊哥：聚簇索引和非聚簇索引有什么区别？
• 浅谈聚簇索引与非聚簇索引
• 聚簇索引、非聚簇索引、联合索引、唯一索引
• 松哥：再聊 MySQL 聚簇索引

---- 这部分是帮助大家理解 end，面试中可不背 ----

1. Java 面试指南（付费）收录的小米春招同学 K 一面面试原题：mysql：聚簇索引和非聚簇索引区别
2. Java 面试指南（付费）收录的支付宝面经同学 2 春招技术一面面试原题：聚簇索引和非聚簇索引的区别？B+树叶子节点除了存数据还有什么？
3. Java 面试指南（付费）收录的字节跳动面经同学 1 Java 后端技术一面面试原题：聚簇索引是什么？非聚簇索引是什么？
4. Java 面试指南（付费）收录的腾讯云智面经同学 16 一面面试原题：聚簇索引和非聚簇索引的区别？
5. Java 面试指南（付费）收录的快手面经同学 1 部门主站技术部面试原题：Mysql 的聚簇索引和非聚簇索引的区别是什么?
6. Java 面试指南（付费）收录的作业帮面经同学 1 Java 后端一面面试原题：mysql的聚簇索引是什么
7. Java 面试指南（付费）收录的腾讯面经同学 29 Java 后端一面原题：MySQL的索引怎么存储的？每个索引一个B+树，还是多个索引放一个B+树？叶子节点中存的是什么数据？

memo：2025 年 4 月 5 日修改至此，今天有拿到美团暑期实习的球友说，简历找二哥修改了两次，基本上不卡第一学历的都有面，很棒。

47.🌟回表了解吗？

当使用非聚簇索引进行查询时，MySQL 需要先通过非聚簇索引找到主键值，然后再根据主键值回到聚簇索引中查找完整数据行，这个过程称为回表。

假设现在有一张用户表 users：

CREATE TABLE users (
    id INT PRIMARY KEY,
    name VARCHAR(50),
    age INT,
    email VARCHAR(50),
    INDEX (name)
);

执行查询：

SELECT * FROM users WHERE name = '王二';

查询过程如下：

• 第一步，MySQL 使用 name 列上的非聚簇索引查找所有 name = '王二' 的主键 id。
• 第二步，使用主键 id 到聚簇索引中查找完整记录。

回表的代价是什么？

回表通常需要访问额外的数据页，如果数据不在内存中，还需要从磁盘读取，增加 I/O 开销。

可通过覆盖索引或者联合索引来避免回表。

-- 原表结构
CREATE TABLE users (
    id INT PRIMARY KEY,
    name VARCHAR(50),
    age INT,
    INDEX idx_name (name)
);

-- 需要查询name和age
SELECT name, age FROM users WHERE name = '张三';
-- 这会回表，因为age不在idx_name索引中

-- 优化方案1：创建包含age的联合索引
ALTER TABLE users ADD INDEX idx_name_age (name, age);
-- 现在同样的查询不需要回表

什么情况下会触发回表？

第一，当查询字段不在非聚簇索引中时，必须回表到主键索引获取数据。

第二，查询字段包含非索引列（如 SELECT *），必然触发回表。

回表记录越多好吗？

回表记录越多，通常代表性能越差，因为每条记录都需要通过主键再查询一次完整数据。这个过程涉及内存访问或磁盘 IO，尤其当缓存命中率不高时，回表会严重影响查询效率。

了解 MRR 吗？

MRR 是 InnoDB 为了解决回表带来的大量随机 IO 问题而引入的一种优化策略。

它会先把非聚簇索引查到的主键值列表进行排序，再按顺序去主键索引中批量回表，将随机 I/O 转换为顺序 I/O，以减少磁盘寻道时间。

---- 这部分是帮助大家理解 start，面试中可不背 ----

可通过 SHOW VARIABLES LIKE 'optimizer_switch'; 查看 MRR 是否启用。

其中 mrr=on 表示启用 MRR，mrr_cost_based=on 表示基于成本决定使用 MRR。

另外可以通过 show variables like 'read_rnd_buffer_size'; 查看 MRR 的缓冲区大小，默认是 256KB。

我们来创建一个表，插入一些数据，然后执行一个查询来演示 MRR 的效果。

CREATE DATABASE IF NOT EXISTS mrr_test; 
USE mrr_test; 
CREATE TABLE IF NOT EXISTS orders (id INT AUTO_INCREMENT PRIMARY KEY, user_id INT, order_date DATE, amount DECIMAL(10,2), status VARCHAR(20), INDEX idx_user_date(user_id, order_date));

DELIMITER //
CREATE PROCEDURE generate_test_data()
BEGIN
    DECLARE i INT DEFAULT 1;
    WHILE i <= 100000 DO
        INSERT INTO orders (user_id, order_date, amount, status)
        VALUES (
            FLOOR(1 + RAND() * 1000),  -- Random user_id between 1 and 1000
            DATE_ADD('2023-01-01', INTERVAL FLOOR(RAND() * 365) DAY),  -- Random date in 2023
            ROUND(10 + RAND() * 990, 2),  -- Random amount between 10 and 1000
            ELT(1 + FLOOR(RAND() * 3), 'completed', 'pending', 'cancelled')  -- Random status
        );
        SET i = i + 1;
    END WHILE;
END //
DELIMITER ;

CALL generate_test_data();
DROP PROCEDURE generate_test_data;"

查看 MRR 开启和关闭时的性能数据：

-- 确保MRR开启并设置足够大的缓冲区
SET SESSION optimizer_switch='mrr=on,mrr_cost_based=off';
SET SESSION read_rnd_buffer_size = 16*1024*1024;

-- 清理缓存和状态
FLUSH STATUS;
FLUSH TABLES;

-- 强制使用二级索引并回表查询（通过选择未被索引的列）
SELECT 'Raw data access pattern with MRR ON' as test_case;
SELECT /*+ MRR(orders_mrr_test) */ id, shipping_address, customer_name
FROM orders_mrr_test FORCE INDEX(idx_user_date)
WHERE user_id IN (100,200,300,400,500,600,700,800,900,1000)
AND order_date BETWEEN '2023-03-01' AND '2023-04-01'
LIMIT 15;

-- 显示处理器状态
SHOW STATUS LIKE 'Handler_%';
SHOW STATUS LIKE '%mrr%';

-- 对比：关闭MRR
SET SESSION optimizer_switch='mrr=off,mrr_cost_based=off';
FLUSH STATUS;
FLUSH TABLES;

SELECT 'Raw data access pattern with MRR OFF' as test_case;
SELECT id, shipping_address, customer_name
FROM orders_mrr_test FORCE INDEX(idx_user_date)
WHERE user_id IN (100,200,300,400,500,600,700,800,900,1000)
AND order_date BETWEEN '2023-03-01' AND '2023-04-01'
LIMIT 15;
-- 显示处理器状态
SHOW STATUS LIKE 'Handler_%';
SHOW STATUS LIKE '%mrr%';

-- 显示详细的执行计划
EXPLAIN FORMAT=TREE
SELECT /*+ MRR(orders_mrr_test) */ id, shipping_address, customer_name
FROM orders_mrr_test FORCE INDEX(idx_user_date)
WHERE user_id IN (100,200,300,400,500,600,700,800,900,1000)
AND order_date BETWEEN '2023-03-01' AND '2023-04-01';"

可以看到 MRR 开启时的结果对比：

Wrap 也给出了对应的结果说明：

也可以在 explain 中确认 MRR 的使用情况。

---- 这部分是帮助大家理解 end，面试中可不背 ----

1. Java 面试指南（付费）收录的字节跳动面经同学 1 Java 后端技术一面面试原题：使用非聚簇索引如何查找数据？
2. Java 面试指南（付费）收录的字节跳动面经同学 1 技术二面面试原题：回表记录越多好吗？（回表的代价）

memo：2025 年 4 月 6 日修改至此，今天帮球友修改简历的时候，看到有球友写技术派到简历上，很不错，推荐给大家。

48.🌟联合索引了解吗？（补充）

2024 年 11 月 22 日增补

联合索引就是把多个字段放在一个索引里，但必须遵守“最左前缀”原则，只有从第一个字段开始连续使用，索引才会生效。

联合索引会按字段顺序构建B+树。例如（age, name）索引会先按照 age 排序，age 相同则按照 name 排序，若两者都相同则按主键排序，确保叶子节点无重复索引项。

创建(A,B,C)联合索引相当于同时创建了(A)、(A,B)和(A,B,C)三个索引。

-- 创建联合索引
CREATE INDEX idx_order_user_product ON orders(user_id, product_id, create_time)

-- 高效查询
SELECT * FROM orders 
WHERE user_id=1001 AND product_id=2002
ORDER BY create_time DESC

联合索引底层的存储结构是怎样的？

联合索引在底层采用 B+ 树结构进行存储，这一点与单列索引相同。

与单列索引不同的是，联合索引的每个节点会存储所有索引列的值，而不仅仅是第一列的值。例如，对于联合索引(a,b,c)，每个节点都包含 a、b、c 三列的值。

非叶子节点示例：  
[(a=1, b=2, c=3) → 子节点1, (a=5, b=3, c=1) → 子节点2]

叶子节点示例（InnoDB）：  
(a=1, b=2, c=3) → PK=100 | (a=1, b=2, c=4) → PK=101  
（通过指针连接形成双向链表）

联合索引的叶子节点存的什么内容?

联合索引属于非聚簇索引，叶子节点存储的是联合索引各列的值和对应行的主键值，而不是完整的数据行。查询非索引字段时，需要通过主键值回表到聚簇索引获取完整数据。

例如索引(a, b)的叶子节点会完整存储(a, b)的值，并按字段顺序排序（如 a 优先，a 相同则按 b 排序）。如果主键是 id，叶子节点会存储 (a, b, id) 的组合。

1. Java 面试指南（付费）收录的百度同学 4 面试原题：联合索引底层存储结构(和其他种类的索引存储结构有什么区别?)联合索引的叶子节点存的什么内容?

memo：2025 年 04 月 07 日增补至此，今天有球友反馈说，加了二哥的星球，简历上写了技术派的项目后，拿到了腾讯天美的 offer，真的太强了。

49.🌟覆盖索引了解吗？

覆盖索引指的是：查询所需的字段全部都在索引中，不需要回表，从索引页就能直接返回结果。

empname 和 job 两个字段是一个联合索引，而查询也恰好是这两个字段，这时候单次查询就可以达到目的，不需要回表。

可以将高频查询的字段（如 WHERE 条件和 SELECT 列）组合为联合索引，实现覆盖索引。

例如：

CREATE INDEX idx_empname_job ON employee(empname, job);

这样查询的时候就可以走索引：

SELECT empname, job FROM employee WHERE empname = '王二' AND job = '程序员';

普通索引只用于加速查询条件的匹配，而覆盖索引还能直接提供查询结果。

一个表（name, sex,age,id），select age,id,name from tblname where name='paicoding';怎么建索引

由于查询条件有 name 字段，所以最少应该为 name 字段添加一个索引。、

CREATE INDEX idx_name ON tblname(name);

查询结果中还需要 age、id 字段，可以为这三个字段创建一个联合索引，利用覆盖索引，直接从索引中获取数据，减少回表。

CREATE INDEX idx_name_age_id ON tblname (name, age, id);

1. Java 面试指南（付费）收录的作业帮面经同学 1 Java 后端一面面试原题：了解覆盖索引吗
2. Java 面试指南（付费）收录的美团同学 9 一面面试原题：覆盖索引，回表？
3. Java 面试指南（付费）收录的字节跳动面经同学 13 Java 后端二面面试原题：一个表（name, sex,age,id），select age,id,name from tblname where name='paicoding';怎么建索引

50.🌟什么是最左前缀原则？

最左前缀原则指的是：MySQL 使用联合索引时，必须从最左边的字段开始匹配，才能命中索引。

假设有一个联合索引 (A, B, C)，其生效条件如下：

如果排序或分组的列是最左前缀的一部分，索引还可以加速操作。

SQL
-- 索引(a,b)
SELECT * FROM table WHERE a = 1 ORDER BY b; -- 可以利用索引排序

范围查询后的列还能用索引吗？

范围查询只能应用于最左前缀的最后一列。范围查询之后的列无法使用索引。

SQL
-- 索引(a,b,c)
SELECT * FROM table WHERE a = 1 AND b > 2 AND c = 3; 
-- 只能使用a和b，c无法使用索引

为什么不从最左开始查，就无法匹配呢？

一句话回答：

因为联合索引在 B+ 树中是按照最左字段优先排序构建的，如果跳过最左字段，MySQL 无法判断查找范围从哪里开始，自然也就无法使用索引。

比如有一个 user 表，我们给 name 和 age 建立了一个联合索引 (name, age)。

ALTER TABLE user add INDEX comidx_name_phone (name,age);

联合索引在 B+ 树中按照从左到右的顺序依次建立搜索树，name 在左，age 在右。

当我们使用 where name= '王二' and age = '20' 去查询的时候， B+ 树会优先比较 name 来确定下一步应该搜索的方向，往左还是往右。

如果 name 相同的时候再比较 age。

但如果查询条件没有 name，就不知道应该怎么查了，因为 name 是 B+树中的前置条件，没有 name，索引就派不上用场了。

联合索引 (a, b)，where a = 1 和 where b = 1，效果是一样的吗

不一样。

WHERE a = 1 能命中联合索引，因为 a 是联合索引的第一个字段，符合最左前缀匹配原则。而 WHERE b = 1 无法命中联合索引，因为缺少 a 的匹配条件，MySQL 会全表扫描。

---- 这部分是帮助大家理解 start，面试中可不背 ----

我们来验证一下，假设有一个 ab 表，建立了联合索引 (a, b)：

CREATE TABLE ab (
    a INT,
    b INT,
    INDEX ab_index (a, b)
);

插入数据：

INSERT INTO ab (a, b) VALUES (1, 2), (1, 3), (2, 1), (3, 3), (2, 2);

执行查询：

通过 explain 可以看到，WHERE a = 1 使用了联合索引，而 WHERE b = 1 需要全表扫描，依次检查每一行。

---- 这部分是帮助大家理解 end，面试中可不背 ----

假如有联合索引 abc，下面的 sql 怎么走的联合索引？

select * from t where a = 2 and b = 2;
select * from t where b = 2 and c = 2;
select * from t where a > 2 and b = 2;

第一条 SQL 语句包含条件 a = 2 和 b = 2，刚好符合联合索引的前两列。

第二条 SQL 语句由于未使用最左前缀中的 a，会触发全表扫描。

第三条 SQL 语句在范围条件 a > 2 之后，索引后会停止匹配，b = 2 的条件需要额外过滤。

(A,B,C) 联合索引 select * from tbn where a=? and b in (?,?) and c>? 会走索引吗？

2024 年 03 月 15 日增补。

这个查询会命中联合索引，因为 a 是等值匹配，b 是 IN 等值多匹配，c 是 b 之后的范围条件，符合最左前缀原则。

1. 对于 a=?：这是一个精确匹配，并且是联合索引的第一个字段，所以一定会命中索引。

2. 对于 b IN (?, ?)：等价于 b=? OR b=?，属于多值匹配，并且是联合索引的第二个字段，所以也会命中索引。

3. 对于 c>?：这是一个范围条件，属于联合索引的第三个字段，也会命中索引。

---- 这部分是帮助大家理解 start，面试中可不背 ----

来验证一下。

第一步，建表。

CREATE TABLE tbn (A INT, B INT, C INT, D TEXT);

第二步，创建索引。

CREATE INDEX idx_abc ON tbn (A, B, C);

第三步，插入数据。

INSERT INTO tbn VALUES (1, 2, 3, 'First');
INSERT INTO tbn VALUES (1, 2, 4, 'Second');
INSERT INTO tbn VALUES (1, 3, 5, 'Third');
INSERT INTO tbn VALUES (2, 2, 3, 'Fourth');
INSERT INTO tbn VALUES (2, 3, 4, 'Fifth');

第四步，执行查询。

EXPLAIN SELECT * FROM tbn WHERE A=1 AND B IN (2, 3) AND C>3\G

从 EXPLAIN 输出结果来看，我们可以得到 MySQL 是如何执行查询的一些关键信息：

• type: 查询类型，这里是 range，表示 MySQL 使用了范围查找，这是因为查询条件包含了 > 操作符。
• possible_keys: 可能被用来执行查询的索引，这里是 idx_abc，表示 MySQL 认为 idx_abc 索引会用于查询优化。
• key: 实际用来执行查询的索引，也是 idx_abc，这确定这条查询命中了联合索引。
• Extra: 提供了关于查询执行的额外信息。Using index condition 表示 MySQL 使用了索引下推（Index Condition Pushdown，ICP），这是 MySQL 的一个优化方式，它允许在索引层面过滤数据。

---- 这部分是帮助大家理解 end，面试中可不背 ----

联合索引的一个场景题：(a,b,c)联合索引，(b,c)是否会走索引吗？

2024 年 04 月 06 日增补

根据最左前缀原则，(b,c) 查询不会走索引。

因为联合索引 (a,b,c) 中，a 是最左边的列，联合索引在创建索引树的时候需要先有 a，然后才会有 b 和 c。而查询条件中没有包含 a，所以 MySQL 无法利用这个索引。

EXPLAIN SELECT * FROM tbn WHERE B=1 AND C=1\G

建立联合索引(a,b,c)，where c = 5 是否会用到索引？为什么？

2024 年 04 月 08 日增补

不会。只有索引的第三列 c 被用作查询条件，而前两列 a 和 b 都没有被使用。这不符合最左前缀原则。

EXPLAIN SELECT * FROM tbn WHERE C=5\G

sql中使用like，如果遵循最左前缀匹配，查询是不是一定会用到索引？

2024 年 11 月 04 日增补

如果查询模式是后缀通配符 LIKE 'prefix%'，且该字段有索引，优化器通常会使用索引。否则即便是遵循最左前缀匹配，LIKE 字段也无法命中索引。

如 age = 18 and name LIKE '%xxx'，MySQL 会先使用联合索引 age_name 找到 age 符合条件的所有行，然后再全表扫描进行 name 字段的过滤。

type: ref 表示使用索引查找匹配某个值的所有行。

如果是后缀通配符，如 age = 18 and name LIKE 'xxx%'，MySQL 会直接使用联合索引 age_name 找到所有符合条件的行。

type 为 range，表示 MySQL 使用了索引范围扫描，filtered 为 100.00%，表示在扫描的行中，所有的行都满足 WHERE 条件。

1. Java 面试指南（付费）收录的字节跳动商业化一面的原题：(A,B,C) 联合索引 select * from tbn where a=? and b in (?,?) and c>? 会走索引吗？
2. Java 面试指南（付费）收录的京东同学 10 后端实习一面的原题：联合索引 abc，a=1,c=1/b=1,c=1/a=1,c=1,b=1 走不走索引
3. Java 面试指南（付费）收录的快手面经同学 7 Java 后端技术一面面试原题：联合索引的一个场景题：(a,b,c)联合索引，(b,c)是否会走索引
4. Java 面试指南（付费）收录的字节跳动面经同学 1 Java 后端技术一面面试原题：建立联合索引(a,b,c)，where c = 5 是否会用到索引？为什么？
5. Java 面试指南（付费）收录的美团面经同学 15 点评后端技术面试原题：sql中使用like，如果遵循最左前缀匹配，查询是不是一定会用到索引？
6. Java 面试指南（付费）收录的比亚迪面经同学 3 Java 技术一面面试原题：说一下数据库索引，最左匹配原则和索引的结构
7. Java 面试指南（付费）收录的腾讯云智面经同学 16 一面面试原题：说说最左前缀原则
8. Java 面试指南（付费）收录的招银网络科技面经同学 9 Java 后端技术一面面试原题：Mysql联合索引的设计原则
9. Java 面试指南（付费）收录的同学 1 贝壳找房后端技术一面面试原题：联合索引 (a, b)，where a = 1 和 where b = 1，效果是一样的吗
10. Java 面试指南（付费）收录的腾讯面经同学 27 云后台技术一面面试原题：（联合索引）下面怎么走的索引？
11. Java 面试指南（付费）收录的滴滴面经同学 3 网约车后端开发一面原题：联合索引 (a, b, c)，where b = 1，能走吗，where a = 1，能走吗

51.🌟什么是索引下推？

索引下推是指：MySQL 把 WHERE 条件尽可能“下推”到索引扫描阶段，在存储引擎层提前过滤掉不符合条件的记录。

当查询条件包含索引列但未完全匹配时，ICP 会在存储引擎层过滤非索引列条件，以减少回表次数。

传统的查询流程是，储引擎通过联合索引定位到符合最左前缀条件的主键 ID；回表读取完整数据行并返回给 Server 层；Server 层对所有返回的行进行 WHERE 条件过滤。

有了 ICP 后，存储引擎在索引层直接过滤可下推的条件，仅对符合索引条件的记录回表读取数据，再返回给 Server 层进行剩余条件过滤。

---- 这部分是帮助大家理解 start，面试中可不背 ----

例如有一张 user 表，建了一个联合索引（name, age），查询语句：select * from user where name like '张%' and age=10;，没有索引下推优化的情况下：

MySQL 会使用索引 name 找到所有 name like '张%' 的主键，根据这些主键，一条条回表查询整行数据，并在 Server 层过滤掉不符合 age=10 的数据行。

启用 ICP 后，InnoDB 会通过联合索引直接筛选出符合条件的主键 ID（name like '张%' and age=10），然后再回表查询整行数据。

换句话说，假设 name like '张%' 找到 10000 行数据，age=10 只有其中 10 行，没有索引下推的情况下，MySQL 会回表 10000 次，读取 10000 行数据，然后在 Server 层过滤掉 9990 行。

而有了索引下推后，MySQL 只会回表 10 次，读取 10 行数据。

我们来验证一下。

从结果中我们可以清楚地看到 ICP 的效果。ICP 开启时，Extra 列显示"Using index condition"，表明过滤条件被下推到存储引擎层。

ICP关闭时，Extra 列仅显示"Using where"，表明过滤条件在服务器层执行。

-- 开启ICP
SET optimizer_switch='index_condition_pushdown=on';

-- 清理状态
FLUSH STATUS;

SELECT 'Performance test with ICP ON' as test_case;
-- 执行查询并分析性能
EXPLAIN ANALYZE
SELECT /*+ ICP_ON */ *
FROM orders_mrr_test
WHERE user_id BETWEEN 100 AND 200
  AND order_date >= '2023-01-01'
  AND order_date < '2023-02-01'
  AND order_date NOT LIKE '2023-01-15%';

-- 显示处理器状态
SHOW STATUS LIKE 'Handler_read%';

-- 关闭ICP
SET optimizer_switch='index_condition_pushdown=off';

-- 清理状态
FLUSH STATUS;

SELECT 'Performance test with ICP OFF' as test_case;
-- 执行相同的查询
EXPLAIN ANALYZE
SELECT *
FROM orders_mrr_test
WHERE user_id BETWEEN 100 AND 200
  AND order_date >= '2023-01-01'
  AND order_date < '2023-02-01'
  AND order_date NOT LIKE '2023-01-15%';

-- 显示处理器状态
SHOW STATUS LIKE 'Handler_read%';"

实际的性能差距也很大。ICP 开启时，实际扫描行数：1,649 行，执行时间：约12.3 毫秒。关闭时，实际扫描行数：19,959 行，执行时间：约 32.1 毫秒。

---- 这部分是帮助大家理解 start，面试中可不背 ----

1. Java 面试指南（付费）收录的美团同学 9 一面面试原题：索引下推

52.如何查看是否用到了索引？（补充）

2024 年 03 月 15 日增补。

可以通过 EXPLAIN 关键字来查看是否使用了索引。

EXPLAIN SELECT * FROM table WHERE column = 'value';

如果使用了索引，结果中的 key 值会显示索引的名称。

联合索引 abc，a=1,c=1/b=1,c=1/a=1,c=1,b=1 走不走索引？

2024 年 03 月 19 日增补

ac 能用上索引，条件 a=1 符合最左前缀原则，触发索引的第一列 a；由于跳过了中间列 b，c=1 无法直接利用索引的有序性优化，但可通过索引下推在存储引擎层过滤 c 的条件，减少回表次数。

bc 无法使用索引，只能全表扫描，因为不符合最左前缀原则；acb 虽然顺序是乱的，但 MySQL 优化器会自动重排为 abc，所以能命中索引。

---- 这部分是帮助大家理解 start，面试中可不背 ----

我们通过实际的 SQL 来验证一下。

示例 1（a=1,c=1）：

EXPLAIN SELECT * FROM tbn WHERE A=1 AND C=1\G

key 是 idx_abc，表明 a=1,c=1 会使用联合索引。Extra: Using index condition 表示 ICP 生效。

示例 2（b=1,c=1）：

EXPLAIN SELECT * FROM tbn WHERE B=1 AND C=1\G

key 是 NULL，表明 b=1,c=1 不会使用联合索引。这是因为查询条件没有遵循最左前缀原则。

示例 3（a=1,c=1,b=1）：

EXPLAIN SELECT * FROM tbn WHERE A=1 AND C=1 AND B=1\G

优化器会自动调整条件顺序为 a=1 AND b=1 AND c=1。

key 是 idx_abc，表明 a=1,c=1,b=1 会使用联合索引。

并且 rows=1，因为 MySQL 优化器会自动重排查询条件，以满足最左前缀原则，直接使用联合索引找出 a=1 AND b=1 AND c=1 的行。

memo：2025 年 4 月 8 日修改至此，今天有球友反馈说，拿到了鹅厂和美团的暑期实习 offer，并且都已经 OC，真的恭喜，又是一个值得晒成绩的日子，哈哈。

锁

53.🌟MySQL 中有哪几种锁？

MySQL 中有多种类型的锁，可以从不同维度来分类，按锁粒度划分的话，有表锁、行锁。

按照加锁机制划分的话，有乐观锁和悲观锁。按照兼容性划分的话，有共享锁和排他锁。

---- 这部分是帮助大家理解 start，面试中可不背 ----

表锁：锁定整个表，资源开销小，加锁快，但并发度低，不会出现死锁；适合查询为主、少量更新的场景（如 MyISAM 引擎）。

再细分的话，有表共享读锁（S锁）：允许多个事务同时读，但阻塞写操作；表独占写锁（X锁）：独占表，阻塞其他事务的读写。

行锁：锁定单行或多行，开销大、加锁慢，可能出现死锁，但并发度高（InnoDB 默认支持）。

再细分的话，有记录锁（Record Lock）：锁定索引中的具体记录；间隙锁（Gap Lock）：锁定索引记录之间的间隙，防止幻读；临键锁（Next-Key Lock）：结合记录锁和间隙锁，锁定一个左开右闭的区间（如 (5, 10]）。

共享锁（S锁/读锁），允许多个事务同时读取数据，但阻塞写操作。语法：SELECT ... LOCK IN SHARE MODE

排他锁（X锁/写锁），独占数据，阻塞其他事务的读写。语法：SELECT ... FOR UPDATE。

乐观锁假设冲突少，通过版本号或 CAS 机制检测冲突（如 UPDATE SET version=version+1 WHERE version=old_version）。

悲观锁假设并发冲突频繁，先加锁再操作SELECT FOR UPDATE。

---- 这部分是帮助大家理解 end，面试中可不背

1. Java 面试指南（付费）收录的京东同学 4 云实习面试原题：mysql一共有哪些锁
2. Java 面试指南（付费）收录的美团面经同学 15 点评后端技术面试原题：问了一下mysql的锁和MVCC
3. Java 面试指南（付费）收录的阿里系面经同学 19 饿了么面试原题：MySQL锁

54.全局锁了解吗？（补充）

2024 年 07 月 15 日增补。

全局锁就是对整个数据库实例进行加锁，当执行全局锁定操作时，整个数据库将会处于只读状态，所有写操作都会被阻塞，直到全局锁被释放。

在进行全库备份，或者数据迁移时，可以使用全局锁来保证数据的一致性。

在 MySQL 中，可以使用 FLUSH TABLES WITH READ LOCK 命令来获取全局锁。

执行该命令后，所有表将被锁定为只读状态。记得在完成备份或迁移后，使用 UNLOCK TABLES 命令释放全局锁。

-- 锁定整个数据库
FLUSH TABLES WITH READ LOCK;

-- 执行备份操作
-- 例如使用 mysqldump 进行备份
! mysqldump -u username -p database_name > backup.sql

-- 释放全局锁定
UNLOCK TABLES;

表锁了解吗？

了解。

表锁常见于 MyISAM 引擎，InnoDB 也可以手动通过 LOCK TABLES 加锁。

适合读多写少、全表扫描或者表结构变更的场景用。

表锁又可以细分为共享锁和排他锁。共享锁允许多个事务同时读表，但不允许写操作。

LOCK TABLES table_name READ;  -- 显式加读锁
SELECT * FROM table_name;     -- 其他会话可读，不可写
UNLOCK TABLES;                -- 释放锁

排他锁只允许一个事务进行写操作，其他事务不能读也不能写。

LOCK TABLES table_name WRITE; -- 显式加写锁
INSERT/UPDATE/DELETE table_name; -- 其他会话读写均阻塞
UNLOCK TABLES;

MyISAM 在执行 SELECT 时会自动加读锁，执行 INSERT/UPDATE/DELETE 时会加写锁。

对于 InnoDB 引擎，无索引的 UPDATE/DELETE 可能会导致锁升级为表锁。

UPDATE innodb_table SET name='new' WHERE name='old'; -- 全表扫描，退化为表锁

执行 ALTER TABLE 时会自动加表锁，阻塞所有读写操作。

1. Java 面试指南（付费）收录的美团面经同学 3 Java 后端技术一面面试原题：数据库中的全局锁 表锁 行级锁 每种锁的应用场景有哪些
2. Java 面试指南（付费）收录的同学 30 腾讯音乐面试原题：mysql的表级锁有几种

55.🌟说说 MySQL 的行锁？

行锁是 InnoDB 存储引擎中最细粒度的锁，它锁定表中的一行记录，允许其他事务访问表中的其他行。

底层是通过给索引加锁实现的，这就意味着只有通过索引条件检索数据时，InnoDB 才能使用行级锁，否则会退化为表锁。

行锁又可以细分为记录锁、间隙锁和临键锁三种形式。通过 SELECT ... FOR UPDATE 可以加排他锁。

START TRANSACTION;

-- 加排他锁，锁定某一行
SELECT * FROM your_table WHERE id = 1 FOR UPDATE;
-- 对该行进行操作
UPDATE your_table SET column1 = 'new_value' WHERE id = 1;

COMMIT;

通过 SELECT ...LOCK IN SHARE MODE 可以加共享锁。

START TRANSACTION;

-- 加共享锁，锁定某一行
SELECT * FROM your_table WHERE id = 1 LOCK IN SHARE MODE;
-- 只能读取该行，不能修改

COMMIT;

select for update 有什么需要注意的？

第一，必须在事务中使用，否则锁会立即释放。

START TRANSACTION;
SELECT * FROM your_table WHERE id = 1 FOR UPDATE;
-- 对该行进行操作
COMMIT;

第二，使用时必须注意是否命中索引，否则可能锁全表。

-- name 没有索引，会退化为表锁
SELECT * FROM user WHERE name = '王二' FOR UPDATE;

---- 这部分是帮助大家理解 start，面试中可不背 ----

假设有一张名为 orders 的表，包含以下数据：

CREATE TABLE orders (
    id INT PRIMARY KEY,
    order_no VARCHAR(255),
    amount DECIMAL(10,2),
    status VARCHAR(50),
    INDEX (order_no)  -- order_no 上有索引
);

表中的数据是这样的：

id	order_no	amount	status
1	10001	50.00	pending
2	10002	75.00	pending
3	10003	100.00	pending
4	10004	150.00	completed
5	10005	200.00	pending

如果我们通过主键索引执行 SELECT FOR UPDATE，确实只会锁定特定的行：

START TRANSACTION;
SELECT * FROM orders WHERE id = 1 FOR UPDATE;
-- 对 id=1 的行进行操作
COMMIT;

由于 id 是主键，所以只会锁定 id=1 这行，不会影响其他行的操作。其他事务依然可以对 id = 2, 3, 4, 5 等行执行更新操作，因为它们没有被锁定。

如果使用 order_no 这个普通索引执行 SELECT FOR UPDATE，也只会锁定特定的行：

START TRANSACTION;
SELECT * FROM orders WHERE order_no = '10001' FOR UPDATE;
-- 对 order_no=10001 的行进行操作
COMMIT;

因为 order_no 是唯一索引，所以只会锁定 order_no=10001 这行，不会影响其他行的操作。

但如果 WHERE 条件是 status='pending'，而 status 上没有索引：

START TRANSACTION;
SELECT * FROM orders WHERE status = 'pending' FOR UPDATE;
-- 对 status=pending 的行进行操作
COMMIT;

就会退化为表锁，因为在这种情况下，MySQL 需要全表扫描检查每一行的 status。

---- 这部分是帮助大家理解 end，面试中可不背 ----

memo：2025 年 4 月 9 日修改至此，今天有球友反馈说，拿到了美团的暑期实习 offer，并且特意感谢了面渣逆袭，口碑+1。

说说记录锁吧？

记录锁是行锁最基本的表现形式，当我们使用唯一索引或者主键索引进行等值查询时，MySQL 会为该记录自动添加排他锁，禁止其他事务读取或者修改锁定记录。

例如：

SELECT * FROM table WHERE id = 1 FOR UPDATE;  -- 加X锁

UPDATE table SET name = '王二' WHERE id = 1; -- 隐式加X锁

间隙锁了解吗？（补充）

2024 年 12 月 15 日增补。

间隙锁用于在范围查询时锁定记录之间的“间隙”，防止其他事务在该范围内插入新记录。仅在可重复读及以上的隔离级别下生效，主要用于防止幻读。

---- 这部分是帮助大家理解 start，面试中可不背 ----

例如事务 A 锁定了 (1000,2000) 区间，会阻止事务 B 在此区间插入新记录：

-- 事务A
BEGIN;
SELECT * FROM orders WHERE amount BETWEEN 1000 AND 2000 FOR UPDATE;

-- 事务B尝试插入会被阻塞
INSERT INTO orders VALUES(null,1500,'pending');  -- 阻塞

假设表 test_gaplock 有 id、age、name 三个字段，其中 id 是主键，age 上有索引，并插入了 4 条数据。

CREATE TABLE `test_gaplock` (
  `id` int(11) NOT NULL,
  `age` int(11) DEFAULT NULL,
  `name` varchar(20) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `age` (`age`)
) ENGINE=InnoDB;

insert into test_gaplock values(1,1,'张三'),(6,6,'吴老二'),(8,8,'赵四'),(12,12,'熊大');

间隙锁会锁住：

• (−∞, 1)：最小记录之前的间隙。
• (1, 6)、(6, 8)、(8, 12)：记录之间的间隙。
• (12, +∞)：最大记录之后的间隙。

假设有两个事务，T1 执行以下语句：

START TRANSACTION;
SELECT * FROM test_gaplock WHERE age > 5 FOR UPDATE;

T2 执行以下语句：

START TRANSACTION;
INSERT INTO test_gaplock VALUES (7, 7, '王五');

T1 会锁住 (6, 8) 的间隙，防止其他事务在这个范围内插入新记录。

T2 在插入 (7, 7, '王五') 时，会被阻塞，可以在另外一个会话中执行 SHOW ENGINE INNODB STATUS 查看到间隙锁的信息。

推荐阅读：六个案例搞懂间隙锁、MySQL中间隙锁的加锁机制

---- 这部分是帮助大家理解 end，面试中可不背 ----

执行什么命令会加上间隙锁？

在可重复读隔离级别下，执行 FOR UPDATE / LOCK IN SHARE MODE 等加锁语句，且查询条件是范围查询时，就会自动加上间隙锁。

-- SELECT ... FOR UPDATE + 范围查询
SELECT * FROM user WHERE score > 100 FOR UPDATE;
-- SELECT ... LOCK IN SHARE MODE + 范围查询
SELECT * FROM user WHERE id BETWEEN 10 AND 20 LOCK IN SHARE MODE;
-- UPDATE/DELETE + 范围查询
DELETE FROM user WHERE score < 50;

1. Java 面试指南（付费）收录的阿里云面经同学 22 面经：mysql的什么命令会加上间隙锁

56.临键锁了解吗？

临键锁是记录锁和间隙锁的结合体，锁住的是索引记录和索引记录之间的间隙。

和间隙锁不同，临键锁的间隙是一个左开右闭区间。例如 (1,3] 表示锁定大于 1 且小于等于 3 的所有记录。

当 InnoDB 执行一个范围查询时，会使用临键锁来锁定满足条件的行数据以及该范围内的间隙。

比如说下面这条语句会锁定 id 在 5 到 10 之间的所有记录，以及这些记录之间的间隙。

SELECT * FROM table WHERE id BETWEEN 5 AND 10 FOR UPDATE;

MySQL 默认的行锁类型就是临键锁。当使用唯一索引的等值查询匹配到一条记录时，临键锁会退化成记录锁；如果没有匹配到任何记录，会退化成间隙锁。

memo：2025 年 4 月 10 日修改至此，今天有学院本的球友反馈说，拿到了滴滴的 sp offer，真的无敌啊，太能卷了。

57.意向锁是什么知道吗？

意向锁是一种表级锁，表示事务打算对表中的某些行数据加锁，但不会直接锁定数据行本身。

由 InnoDB 自动管理，当事务需要添加行锁时，会先在表上添加意向锁。这样当要添加表锁的时候，可以通过查看表上的意向锁，快速判断是否有冲突，而无需逐行检查，从而提高加锁效率。

当执行 SELECT ... LOCK IN SHARE MODE 时，会自动加意向共享锁；当执行 SELECT ... FOR UPDATE 时，会自动加意向排他锁。

意向锁之间互相兼容，也不会与行锁冲突。

兼容关系	意向共享锁	意向排他锁	共享锁(表级)	拍他锁(表级)
意向共享锁	兼容	兼容	兼容	冲突
意向排他锁	兼容	兼容	冲突	冲突
S锁	兼容	冲突	兼容	冲突
X锁	冲突	冲突	冲突	冲突

意向锁的意义是什么？

在没有意向锁的情况下，当事务 A 持有某表的行锁时，如果事务 B 想添加表锁，InnoDB 必须检查表中每一行数据是否被加锁，这种全表扫描的方式效率极低。

有了意向锁之后，事务在加行锁前，先在表上加对应的意向锁；其他事务加表锁时，只需检查表上的意向锁，无需逐行检查。

-- 事务A获取某行的排他锁
BEGIN;
SELECT * FROM users WHERE id = 6 FOR UPDATE;  -- 自动加IX锁和行X锁

-- 事务B尝试加表锁
LOCK TABLES users READ;  -- 发现表上有IX锁，与S锁冲突，直接阻塞而无需扫描全表

memo：2025 年 4 月 11 日修改至此，今天拿到滴滴 offer 的球友反馈，MQ 部分主要看的面渣逆袭，比较全，这不，口碑就来了。

58.🌟MySQL的乐观锁和悲观锁了解吗？

悲观锁是一种"先上锁再操作"的保守策略，它假设数据被外界访问时必然会产生冲突，因此在数据处理过程中全程加锁，保证同一时间只有一个线程可以访问数据。

MySQL 中的行锁和表锁都是悲观锁。

乐观锁会假设并发操作不会总发生冲突，属于小概率事件，因此不会在读取数据时加锁，而是在提交更新时才检查数据是否被其他事务修改过。

乐观锁并不是 MySQL 内置的锁机制，而是通过程序逻辑实现的，常见的实现方式有版本号机制和时间戳机制。通过在表中增加 version 字段或者 timestamp 字段来实现。

---- 这部分是帮助大家理解 start，面试中可不背 ----

当事务 A 已经上锁后，事务 B 会一直等待事务 A 释放锁；如果事务 A 长时间不释放锁，事务 B 就会报错 Lock wait timeout exceeded; try restarting transaction。

事务 A 和事务 B 同时读取同一个主键 ID 的数据，版本号为 0；事务 A 将版本号（version=1）作为条件进行数据更新，同时版本号 +1；事务 B 也将 version=1 作为更新条件，发现版本号不匹配，更新失败。

---- 这部分是帮助大家理解 end，面试中可不背 ----

如何通过悲观锁和乐观锁解决库存超卖问题？

悲观锁通过 SELECT ... FOR UPDATE 在查询时直接锁定记录，确保其他事务必须等待当前事务完成才能操作该行数据。

BEGIN;
-- 对id=1的商品记录加排他锁
SELECT stock FROM products WHERE id=1 FOR UPDATE;
-- 生成订单
INSERT INTO orders (user_id, product_id) VALUES (123, 1);
-- 扣减库存
UPDATE products SET stock=stock-1 WHERE id=1;
COMMIT;

乐观锁通过在表中增加 version 字段作为判断条件。

-- 查询商品信息，获取版本号
SELECT stock, version FROM products WHERE id=1;

-- 更新库存时检查版本号
UPDATE products 
SET stock=stock-1, version=version+1 
WHERE id=1 AND version=旧版本号;

---- 这部分是帮助大家理解 start，面试中可不背 ----

库存超卖是一个非常经典的问题：

• 事务A查询商品库存，得到库存值为1
• 事务B也查询同一商品库存，同样得到库存值为1
• 事务A基于查询结果执行库存扣减，将库存更新为0
• 事务B也执行库存扣减，将库存更新为-1

悲观锁的关键点：

• 必须在一个事务中执行；
• 通过 SELECT ... FOR UPDATE 锁定行，确保其他事务必须等待当前事务完成才能操作该行数据；
• 记得给查询条件加索引，避免全表扫描导致锁升级为表锁。

乐观锁的关键点：

• 在表中增加 version 字段；
• 查询时获取当前版本号；
• 更新时检查版本号是否发生了变化。

Java 程序的完整代码示例：

@Service
public class ProductService {
    @Autowired
    private ProductMapper productMapper;
    
    @Transactional
    public boolean purchaseWithOptimisticLock(Long productId, int quantity) {
        int retryCount = 0;
        while(retryCount < 3) { // 最大重试次数
            Product product = productMapper.selectById(productId);
            if(product.getStock() < quantity) {
                return false; // 库存不足
            }
            
            int updated = productMapper.reduceStockWithVersion(
                productId, quantity, product.getVersion());
                
            if(updated > 0) {
                return true; // 更新成功
            }
            retryCount++;
        }
        return false; // 更新失败
    }
}

对应的 mapper：

@Update("UPDATE products SET stock=stock-#{quantity}, version=version+1 " +
        "WHERE id=#{productId} AND version=#{version}")
int reduceStockWithVersion(@Param("productId") Long productId, 
                          @Param("quantity") int quantity,
                          @Param("version") int version);

时间戳机制实现的乐观锁：

UPDATE products SET stock=stock-1, update_time=NOW() 
WHERE id=1 AND update_time=旧时间戳;

这两种方式都需要保证操作的原子性，需要将多个 SQL 放在同一个事务中执行。

推荐阅读：牧小农：悲观锁和乐观锁

---- 这部分是帮助大家理解 end，面试中可不背 ----

1. Java 面试指南（付费）收录的小公司面经合集同学 1 Java 后端面试原题：乐观锁和悲观锁，库存的超卖问题的原因和解决方案？
2. Java 面试指南（付费）收录的京东面经同学 5 Java 后端技术一面面试原题：乐观锁与悲观锁

memo：2025 年 4 月 12 日修改至此，今天有球友反馈说，京东进入 HR 面了，但加了一个 VP 级别的面试，副总监，等一手他的好消息。当然了，仍然不忘感谢一下面渣逆袭对他的帮助，哈哈。

59.遇到过MySQL死锁问题吗，你是如何解决的？

遇到过。MySQL 的死锁是由于多个事务持有资源并相互等待引起的。我通过 SHOW ENGINE INNODB STATUS 查看死锁信息，定位到是加锁顺序不一致导致的，最后通过调整加锁顺序解决了这个问题。

比如说技术派项目中，两个事务分别更新两张表，但是更新顺序不一致。

-- 创建表/插入数据
CREATE TABLE account (
    id INT AUTO_INCREMENT PRIMARY KEY,
    balance INT NOT NULL
);

INSERT INTO account (balance) VALUES (100), (200);

-- 事务 1
START TRANSACTION;
-- 锁住 id=1 的行
UPDATE account SET balance = balance - 10 WHERE id = 1;

-- 等待锁住 id=2 的行（事务 2 已锁住）
UPDATE account SET balance = balance + 10 WHERE id = 2;

-- 事务 2
START TRANSACTION;
-- 锁住 id=2 的行
UPDATE account SET balance = balance - 10 WHERE id = 2;

-- 等待锁住 id=1 的行（事务 1 已锁住）
UPDATE account SET balance = balance + 10 WHERE id = 1;

访问相同的资源，但顺序不同，就会导致死锁。

解决办法也很简单，先使用 SHOW ENGINE INNODB STATUS\G; 确认死锁的具体信息，然后调整资源的访问顺序。

1. Java 面试指南（付费）收录的虾皮面经同学 13 一面面试原题：遇到过mysql死锁或者数据不安全吗

事务

60.🌟MySQL事务的四大特性说一下？

事务是一条或多条 SQL 语句组成的执行单元。四个特性分别是原子性、一致性、隔离性和持久性。原子性保证事务中的操作要么全部执行、要么全部失败；一致性保证数据从事务开始前的一个一致状态转移到结束后的另外一个一致状态；隔离性保证并发事务之间互不干扰；持久性保证事务提交后数据不会丢失。

详细说一下原子性？

原子性意味着事务中的所有操作要么全部完成，要么全部不完成，它是不可分割的单位。如果事务中的任何一个操作失败了，整个事务都会回滚到事务开始之前的状态，如同这些操作从未被执行过一样。

START TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE user_id = 1;
UPDATE accounts SET balance = balance + 100 WHERE user_id = 2;
-- 如果第二条语句失败，第一条也会回滚
COMMIT;

简短回答：原子性要求事务的所有操作要么全部提交成功，要么全部失败回滚，对于一个事务中的操作不能只执行其中一部分。

详细说一下一致性？

一致性确保事务从一个一致的状态转换到另一个一致的状态。

比如在银行转账事务中，无论发生什么，转账前后两个账户的总金额应保持不变。假如 A 账户（100 块）给 B 账户（10 块）转了 10 块钱，不管成功与否，A 和 B 的总金额都是 110 块。

-- 假设 A 账户余额为 100，B 账户余额为 10

-- 转账前状态
SELECT balance FROM accounts WHERE user_id = 'A'; -- 100
SELECT balance FROM accounts WHERE user_id = 'B'; -- 10

-- 转账操作
START TRANSACTION;
UPDATE accounts SET balance = balance - 10 WHERE user_id = 'A';
UPDATE accounts SET balance = balance + 10 WHERE user_id = 'B';
COMMIT;

-- 转账后状态
SELECT balance FROM accounts WHERE user_id = 'A'; -- 90
SELECT balance FROM accounts WHERE user_id = 'B'; -- 20`
-- 总金额仍然是 110

简短回答：一致性确保数据的状态从一个一致状态转变为另一个一致状态。一致性与业务规则有关，比如银行转账，不论事务成功还是失败，转账双方的总金额应该是不变的。

详细说一下隔离性？

隔离性意味着并发执行的事务是彼此隔离的，一个事务的执行不会被其他事务干扰。事务之间是井水不犯河水的。

隔离性主要是为了解决事务并发执行时可能出现的脏读、不可重复读、幻读等问题。

---- 这部分是帮助大家理解 start，面试中可不背 ----

比如说在读未提交的隔离级别下，会出现脏读现象：一个事务C 读取了事务B 尚未提交的修改数据。如果事务B 最终回滚，事务C 读取的数据就是无效的“脏数据”。

-- 会话 A
-- 创建模拟并发的测试表
DROP TABLE IF EXISTS accounts;
CREATE TABLE accounts (
    id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(50),
    balance DECIMAL(10,2)
);

-- 插入测试数据
INSERT INTO accounts (name, balance) VALUES
('王二', 1000.00),
('张三', 2000.00),
('李四', 3000.00);

-- 会话B 中，设置隔离级别为读未提交
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
START TRANSACTION;

-- 在会话 B 中更新数据但不提交
UPDATE accounts SET balance = balance - 500 WHERE name='王二';

-- 会话C 是读为提交级别，读取数据，得到 500
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SELECT * FROM accounts WHERE name='王二';
-- 继续别的操作，基于 500

-- 会话 B 的事务回滚，导致会话 A 读到的数据其实是脏数据
ROLLBACK;

通过升级隔离级别为读已提交可以解决脏读的问题。

-- 会话 B 修改为读已提交
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

-- 执行第一次查询 1000
SELECT * FROM accounts WHERE name='王二';

-- 会话 C 中，设置隔离级别为读已提交
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
-- 在会话 C 中更新数据但不提交
START TRANSACTION;
UPDATE accounts SET balance = balance + 200 WHERE name='王二';

-- 会话 B 中再次读取数据，结果仍然为 1000
SELECT * FROM accounts WHERE name='王二';

-- 会话 C 中回滚事务
ROLLBACK;
-- 会话 B 中再次读取数据，结果仍然为 1000
SELECT * FROM accounts WHERE name='王二';

但会出现不可重复读的问题：事务B 第一次读取某行数据值为X，期间事务C修改该数据为Y并提交，事务B 再次读取时发现值变为Y，导致两次读取结果不一致。

-- 会话 B 修改为读已提交
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

-- 执行第一次查询 1000
START TRANSACTION;
SELECT * FROM accounts WHERE name='王二';

-- 会话 C 中，设置隔离级别为读已提交
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
-- 在会话 C 中更新数据并提交
START TRANSACTION;
UPDATE accounts SET balance = balance + 200 WHERE name='王二';
-- 会话 C 提交事务
COMMIT;

-- 会话 B 中再次读取数据，结果仍然为 1200
SELECT * FROM accounts WHERE name='王二';

可以通过升级隔离级别为可重复读来解决不可重复读的问题。

-- 会话 B 修改为可重复读
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;

-- 开始事务并执行第一次查询 1000
START TRANSACTION;
SELECT * FROM accounts WHERE name='王二';

-- 会话 C 中，设置隔离级别为可重复读
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
-- 在会话 C 中更新数据并提交
START TRANSACTION;
UPDATE accounts SET balance = balance + 200 WHERE name='王二';
-- 会话 C 提交事务
COMMIT;

-- 会话 B 中再次读取数据，结果仍然为 1000
SELECT * FROM accounts WHERE name='王二';

但可重复读级别下仍然会出现幻读的问题：事务B 第一次查询获得 2条数据，事务C 新增 1条数据并提交后，事务B 再次查询时仍然为 2 条数据，但可以更新新增的数据，再次查询时就发现有 3 条数据了。

-- 会话 B 修改为可重复读
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
-- 执行第一次查询，查到 2 条记录
START TRANSACTION;
SELECT * FROM accounts WHERE balance > 1000;

-- 会话 C 中，设置隔离级别为可重复读
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
-- 在会话 C 中新增数据并提交
START TRANSACTION;
INSERT INTO accounts (name, balance) VALUES ('王五', 4000);
-- 会话 C 提交事务
COMMIT;

-- 会话 B 中再次读取数据，结果仍然为 2 条
SELECT * FROM accounts WHERE balance > 1000;
-- 会话 B 中尝试更新王五的余额为 5000，竟然成功了
UPDATE accounts SET balance = 5000 WHERE name='王五';
-- 会话 B 中再次读取数据，发现 3 条记录
SELECT * FROM accounts WHERE balance > 1000;

可以通过升级隔离级别为串行化来解决幻读的问题。

-- 会话 B 修改为可串行化
SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;
-- 执行第一次查询，查到 2 条记录
START TRANSACTION;
SELECT * FROM accounts WHERE balance > 1000;

-- 会话 C 中，设置隔离级别为可串行化
SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;
-- 在会话 C 中新增数据，会卡住
START TRANSACTION;
INSERT INTO accounts (name, balance) VALUES ('王五', 4000);
-- 只有等会话 B 提交事务后会话 C 才会继续执行并提交事务
COMMIT;

隔离级别	是否会脏读	是否会不可重复读	是否会幻读
Read Uncommitted（读未提交）	✅ 可能	✅ 可能	✅ 可能
Read Committed（读已提交）	❌ 不会	✅ 可能	✅ 可能
Repeatable Read（可重复读）	❌ 不会	❌ 不会	✅ 可能（但 InnoDB 已解决）
Serializable（可串行化）	❌ 不会	❌ 不会	❌ 不会

---- 这部分是帮助大家理解 end，面试中可不背 ----

简短回答：多个并发事务之间需要相互隔离，即一个事务的执行不能被其他事务干扰。

详细说一下持久性？

持久性确保事务一旦提交，它对数据所做的更改就是永久性的，即使系统发生崩溃，数据也能恢复到最近一次提交的状态。

MySQL 的持久性是通过 InnoDB 引擎的 redo log 实现的。在事务提交时，InnoDB 会先将修改操作写入 redo log，并刷盘持久化。崩溃后，InnoDB 会通过 redo log 恢复数据，从而保证事务提交成功的数据不会丢失。

简短回答：一旦事务提交，则其所做的修改将永久保存到 MySQL 中。即使发生系统崩溃，修改的数据也不会丢失。

1. Java 面试指南（付费）收录的京东同学 10 后端实习一面的原题：事务的四个特性，怎么理解事务一致性
2. Java 面试指南（付费）收录的美团面经同学 16 暑期实习一面面试原题：MySQL 事务是什么，默认隔离级别，什么是可重复读？
3. Java 面试指南（付费）收录的腾讯面经同学 23 QQ 后台技术一面面试原题：MySQL 事务，隔离级别
4. Java 面试指南（付费）收录的字节跳动面经同学 1 Java 后端技术一面面试原题：什么是数据库事务？事务的作用是什么？
5. Java 面试指南（付费）收录的 OPPO 面经同学 1 面试原题：对MySQL事务的理解
6. Java 面试指南（付费）收录的vivo 面经同学 10 技术一面面试原题：事务的概念
7. Java 面试指南（付费）收录的同学 1 贝壳找房后端技术一面面试原题：事务ACID
8. Java 面试指南（付费）收录的字节跳动同学 17 后端技术面试原题：什么是事务 事务为什么要有隔离级别 幻读是什么 什么时候要解决幻读 什么时候不用解决
9. Java 面试指南（付费）收录的字节跳动面经同学19番茄小说一面面试原题：MySQL中的事务

memo：2025 年 4 月 13 日修改至此，今天给球友改简历的时候，发现这种彩虹屁真的离谱了，直接配享太庙了，但有一说一这位球友的话是真的甜，简历写的确实也很用心了，确定一个 offer 收割机。

61.ACID 靠什么保证的呢？

一句话总结：

ACID 中的原子性主要通过 Undo Log 来实现，持久性通过 Redo Log 来实现，隔离性由 MVCC 和锁机制来实现，一致性则由其他三大特性共同保证。

详细说说如何保证原子性？

事务对数据进行修改前，会记录一份快照到 Undo Log，如果事务中有任何一步执行失败，系统会读取 Undo Log 将所有操作回滚，恢复到事务开始前的状态，从而保证事务要么全部成功，要么全部失败。

1）BEGIN;

2）UPDATE user SET balance = balance - 100 WHERE id = 1;
   => 写入 Undo Log：记录 id=1 的原始余额 500

3）UPDATE user SET balance = balance + 100 WHERE id = 2;
   => 写入 Undo Log：记录 id=2 的原始余额 300

4）COMMIT;
   => 清空 Undo Log，事务成功

❗如果失败：
   => 执行 ROLLBACK：根据 Undo Log 把数据还原！

推荐阅读：庖丁解InnoDB之UNDO LOG

详细说说如何保证持久性？

MySQL 的持久性主要由预写 Redo Log、双写机制、两阶段提交以及 Checkpoint 刷盘机制共同保证。

当事务提交时，MySQL 会先将事务的修改操作写入 Redo Log，并强制刷盘，然后再将内存中的数据页刷入磁盘。这样即使系统崩溃，重启后也能通过 Redo Log 重放恢复数据。

在将数据页写入到磁盘时，如果发生崩溃，可能会导致数据页不完整。InnoDB 的数据页大小为16KB，通常大于操作系统的 4KB页大小。

为了解决只写入部分的问题，MySQL 采用了双写机制，脏盘刷页时，先将数据页写入到一个双写缓冲区中，2M 的连续空间，然后再将其写入到磁盘的实际位置。

崩溃恢复时，如果发现数据页不完整，会从双写缓冲区中恢复副本，确保数据页的完整性。

在涉及主从复制时，MySQL 通过两阶段提交保证 Redo Log 和 Binlog 的一致性：第一阶段，写入 Redo Log 并标记为 prepare 状态；第二阶段，写入 Binlog 再提交 Redo Log 为 commit 状态。

崩溃恢复时，如果发现 Redo Log 是 prepare 但 Binlog 完整，则会提交事务；反之会回滚，避免主从不一致。

另外，由于 Redo Log 的容量有限，Checkpoint 机制会定期将内存中的脏页刷到磁盘，这样能减少崩溃恢复时需要处理的 Redo Log 数量。

推荐阅读：深入解析MySQL双写缓冲区、MySQL 事务二阶段提交

详细说说如何保证隔离性？

隔离性主要通过锁机制和 MVCC 来实现。

比如说一个事务正在修改某条数据时，MySQL 会通过临键锁来防止其他事务同时进行修改，避免数据冲突。

同时，临键锁可以防止幻读现象的发生。比如事务 A 查询 id > 10 的记录，那么临键锁不仅会锁住 id=10 的行，还会锁住 10 后面的“间隙”，防止其他事务插入 id=15 的数据。

假如表中的主键有 id: 5, 10, 15, 20, 25，那么 InnoDB 会对以下区间和记录加锁：

加锁对象	类型	锁定含义
(10, 15]	临键锁	锁住 id=15 和前间隙，防止插入11~14
(15, 20]	临键锁	锁住了 id=20 和前间隙
(20, 25]	临键锁	锁住了 id=25 和前间隙
(25, +∞)	间隙锁	锁住尾部防止插入30等

MVCC 主要用来优化读操作，通过保存数据的历史版本，让读操作不需要加锁就能直接读取快照，提高读的并发性能。

不同的隔离级别对应不同的实现策略，比如说在可重复读隔离级别下，事务第一次查询时会生成一个 Read View，之后所有读操作都复用这个视图，保证多次读取的结果一致。

如何保证一致性呢？

MySQL 的一致性并不是靠某一个机制单独保证的，而是原子性、隔离性和持久性协同作用的结果。

事务会不会自动提交？

是的，MySQL 默认开启了事务自动提交模式。

每条单独的 SQL 语句都会被视为一个独立的事务处理单元；SQL 语句执行成功后会自动执行 COMMIT；执行失败时会自动 ROLLBACK。

可通过 SELECT @@autocommit; 查看当前会话的自动提交状态。

如果需要执行多条 SQL 语句，可以将它们放在一个事务中，使用 START TRANSACTION 开启事务，执行完所有 SQL 语句后手动提交。

START TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE user_id = 1;
UPDATE accounts SET balance = balance + 100 WHERE user_id = 2;
COMMIT;

1. Java 面试指南（付费）收录的美团同学 2 优选物流调度技术 2 面面试原题：MySQL ACID 哪些机制来保证
2. Java 面试指南（付费）收录的百度同学 4 面试原题：事务会不会自动提交?

memo：2025 年 4 月 14 日修改至此，昨天有球友发帖说拿到了字节、美团的暑期实习 offer，双非本末 9 硕，全文很硬，强烈推荐大家看看，差不多有 3000 多字，详细剖析了自己的准备过程。

62.🌟事务的隔离级别有哪些？

隔离级别定义了一个事务可能受其他事务影响的程度，MySQL 支持四种隔离级别，分别是：读未提交、读已提交、可重复读和串行化。

读未提交会出现脏读，读已提交会出现不可重复读，可重复读是 InnoDB 默认的隔离级别，可以避免脏读和不可重复读，但会出现幻读。不过通过 MVCC 和临键锁，能够防止大多数并发问题。

串行化最安全，但性能较差，通常不推荐使用。

详细说说读未提交？

事务可以读取其他未提交事务修改的数据。也就是说，如果未提交的事务一旦回滚，读取到的数据就会变成了“脏数据”，通常不会使用。

什么是读已提交？

读已提交避免了脏读，但可能会出现不可重复读，即同一事务内多次读取同一数据结果会不同，因为其他事务提交的修改，对当前事务是可见的。

是 Oracle、SQL Server 等数据库的默认隔离级别。

什么是可重复读？

可重复读能确保同一事务内多次读取相同数据的结果一致，即使其他事务已提交修改。

是 MySQL 默认的隔离级别，避免了“脏读”和“不可重复读”，通过 MVCC 和临键锁也能在一定程度上避免幻读。

-- Session A:
START TRANSACTION;
SELECT balance FROM accounts WHERE id=1; --返回500

-- Session B:
UPDATE accounts SET balance = balance +100 WHERE id=1;
COMMIT;

-- Session A再次查询:
SELECT balance FROM accounts WHERE id=1; --仍返回500(可重复读)

-- Session A更新后查询:
UPDATE accounts SET balance = balance +50 WHERE id=1; --基于最新值550更新为600 
SELECT balance FROM accounts WHERE id=1; --返回600 

什么是串行化？

串行化是最高的隔离级别，通过强制事务串行执行来解决“幻读”问题。

但会导致大量的锁竞争问题，实际应用中很少用。

A 事务未提交，B 事务上查询到的是旧值还是新值？

如果 B 是普通的 SELECT，也就是快照读，它读的是旧值，即事务 A 修改前的快照，并且不会阻塞；如果 B 是当前读，比如 SELECT … FOR UPDATE，它会被阻塞直到事务 A 提交或回滚。

-- 会话 A 中，更新王二的余额
START TRANSACTION;
UPDATE accounts SET balance = 8000 WHERE name = '王二';
-- 此时并没有 COMMIT

-- 会话 B 中查询王二的余额
SELECT * FROM accounts WHERE name = '王二';
-- 会话 B 会读取到 旧值 1000

-- 会话 C 中使用当前读查询王二的余额
SELECT * FROM accounts WHERE name = '王二' FOR UPDATE;
-- 会话 C 会被阻塞，直到会话 A 提交或回滚

怎么更改事务的隔离级别？

MySQL 支持通过 SET 语句修改事务隔离级别，包括全局级别、当前会话，但一般不建议在生产环境中随意修改隔离级别。

测试环境下可以使用 SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ; 可以修改当前会话的隔离级别。

使用 SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED; 可以修改全局隔离级别，影响新的连接，但不会改变现有会话。

1. Java 面试指南（付费）收录的美团面经同学 16 暑期实习一面面试原题：MySQL 事务是什么，默认隔离级别，什么是可重复读？
2. Java 面试指南（付费）收录的腾讯面经同学 23 QQ 后台技术一面面试原题：MySQL 事务，隔离级别
3. Java 面试指南（付费）收录的快手面经同学 7 Java 后端技术一面面试原题：说一下事务的四大隔离级别，分别解决什么问题
4. Java 面试指南（付费）收录的字节跳动面经同学 1 Java 后端技术一面面试原题：MySQL 默认隔离级别？
5. Java 面试指南（付费）收录的美团面经同学 2 Java 后端技术一面面试原题：说说 MySQL 事务的隔离级别，如何实现？
6. Java 面试指南（付费）收录的小公司面经合集同学 1 Java 后端面试原题：MySQL 的四个隔离级别以及默认隔离级别？
7. Java 面试指南（付费）收录的 360 面经同学 3 Java 后端技术一面面试原题：数据库隔离级别有哪些？mysql 是属于哪个隔离级别
8. Java 面试指南（付费）收录的联想面经同学 7 面试原题：Mysql 四个隔离级别，MVCC 实现
9. Java 面试指南（付费）收录的oppo 面经同学 8 后端开发秋招一面面试原题：讲讲Mysql的四个隔离级别
10. Java 面试指南（付费）收录的比亚迪面经同学 12 Java 技术面试原题：mysql的隔离级别有哪些
11. Java 面试指南（付费）收录的腾讯面经同学 27 云后台技术一面面试原题：事务的隔离级别？这些隔离级别是怎么保证数据的一致性的？默认的事务隔离级别是啥？（MVCC）怎么更改事务的隔离级别？
12. Java 面试指南（付费）收录的字节跳动面经同学19番茄小说一面面试原题：事务隔离级别，哪个是默认的，特点
13. Java 面试指南（付费）收录的虾皮面经同学 13 一面面试原题：mysql事务隔离级别

63.事务的隔离级别是如何实现的？

读未提交通过行锁共享锁确保一个事务在更新行数据但没有提交的情况下，其他事务不能更新该行数据，但不会阻止脏读，意味着事务2 可以在事务1 提交之前读取到事务1 修改的数据。

读已提交会在更新数据前加行级排他锁，不允许其他事务写入或者读取未提交的数据，也就意味着事务2 不能在事务 1 提交之前读取到事务1 修改的数据，从而解决脏读的问题。

另外，读已提交会在每次读取数据前都生成一个新的 ReadView，所以会出现不可重复读的问题。

可重复读只在第一次读操作时生成 ReadView，后续读操作都会使用这个 ReadView，从而避免不可重复读的问题。

另外，对于当前读操作，可重复读会通过临键锁来锁住当前行和前间隙，防止其他事务在这个范围内插入数据，从而避免幻读的问题。

串行化级别下，事务在读操作时，会先加表级共享锁；在写操作时，会先加表级排他锁。

直到事务结束后才释放锁，这样就能确保事务之间不会相互干扰。

1. Java 面试指南（付费）收录的美团面经同学 2 Java 后端技术一面面试原题：说说 MySQL 事务的隔离级别，如何实现？
2. Java 面试指南（付费）收录的得物面经同学 9 面试题目原题：Mysql隔离机制有哪些？怎么实现的？可串行化是怎么避免的三个事务问题？
3. Java 面试指南（付费）收录的滴滴面经同学 3 网约车后端开发一面原题：可重复读级别是怎么实现的

memo：2025 年 4 月 17 日修改至此，今天有球友发微信说拿到京东的暑期实习 offer，并且今天 VIP 9 群有球友说今天是晒 offer 日，因为 9 群有好几个球友拿到了大厂 offer，后面我再同步给大家。

64.🌟请详细说说幻读呢？

幻读是指在同一个事务中，多次执行相同的范围查询，结果却不同。这种现象通常发生在其他事务在两次查询之间插入或删除了符合当前查询条件的数据。

---- 这部分是帮助大家理解 start，面试中可以不背 ----

比如说事务 A 在第一次查询某个条件范围的数据行后，事务 B 插入了一条新数据且符合条件范围，事务 A 再次查询时，发现多了一条数据。

我们来验证一下，先创建测试表，插入测试数据。

CREATE TABLE `user_info` (
  `id` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键id',
  `name` VARCHAR(32) NOT NULL DEFAULT '' COMMENT '姓名',
  `gender` VARCHAR(32) NOT NULL DEFAULT '' COMMENT '性别',
  `email` VARCHAR(32) NOT NULL DEFAULT '' COMMENT '邮箱',
  PRIMARY KEY (`id`)
) ENGINE=INNODB DEFAULT CHARSET=utf8mb4 COMMENT='用户信息表';

-- 插入测试数据
INSERT INTO `user_info` (`id`, `name`, `gender`, `email`) VALUES 
  (1, 'Curry', '男', 'curry@163.com'),
  (2, 'Wade', '男', 'wade@163.com'),
  (3, 'James', '男', 'james@163.com');

COMMIT;

然后我们在事务 A 中执行查询 SELECT * FROM user_info WHERE id > 1;，在事务 B 中插入数据 INSERT INTO user_info (name, gender, email) VALUES ('wanger', '女', 'wanger@163.com');，再在事务 A 中修改刚刚插入的数据 update user_info set gender='男' where id = 4;，最后在事务 A 中再次查询 SELECT * FROM user_info WHERE id > 1;。

---- 这部分是帮助大家理解 end，面试中可以不背 ----

如何避免幻读？

MySQL 在可重复读隔离级别下，通过 MVCC 和临键锁可以在一定程度上避免幻读。

比如说在查询时显示加锁，利用临键锁锁定查询范围，防止其他事务插入新的数据。

START TRANSACTION;
SELECT * FROM user_info WHERE id > 1 FOR UPDATE; -- 加临键锁
COMMIT;

其他事务在插入数据时，会被阻塞，直到当前事务提交或回滚。

---- 这部分是帮助大家理解 start，面试中可以不背 ----

解释一下。

如果查询语句中包含显式加锁（如 FOR UPDATE），InnoDB 会使用当前读，直接读取最新的数据，并加锁。

在范围查询时，InnoDB 不仅会对符合条件的记录加行锁，还会对相邻的索引间隙加间隙锁，从而形成临键锁。

临键锁可以防止其他事务在间隙中插入新数据，从而避免幻读。

---- 这部分是帮助大家理解 end，面试中可以不背 ----

比如说在执行查询的事务中，不要尝试去更新其他事务插入/删除的数据，利用快照读来避免幻读。

---- 这部分是帮助大家理解 start，面试中可以不背 ----

使用 SELECT 查询时，如果没有显式加锁，InnoDB 会使用 MVCC 提供一致性视图。

每个事务在启动时都会生成一个 Read View，用来确定哪些数据对当前事务可见。

其他事务在当前事务启动后插入的新数据不会被当前事务看到，因此不会出现幻读。

---- 这部分是帮助大家理解 end，面试中可以不背 ----

什么是当前读呢？

当前读是指读取记录的最新已提交版本，并且在读取时对记录加锁，确保其他并发事务不能修改当前记录。

比如 SELECT ... LOCK IN SHARE MODE、SELECT ... FOR UPDATE，以及 UPDATE、DELETE，都属于当前读。

为什么 UPDATE 和 DELETE 也属于当前读？

因为更新、删除这些操作，本质上不仅是写操作，还需要在写之前读取数据，然后才能修改或删除。为了保证修改的是最新的数据，并防止并发冲突，InnoDB 必须读取最新版本的数据并加锁，因此 UPDATE 和 DELETE 也属于当前读。

SQL语句	是否当前读	是否加锁
SELECT * FROM user WHERE id=1	❌ 否	❌ 否
SELECT * FROM user WHERE id=1 FOR UPDATE	✅ 是	✅ 加排他锁
SELECT * FROM user WHERE id=1 LOCK IN SHARE MODE	✅ 是	✅ 加共享锁
UPDATE user SET ... WHERE id=1	✅ 是	✅ 加排他锁
DELETE FROM user WHERE id=1	✅ 是	✅ 加排他锁

什么是快照读呢？

快照读是 InnoDB 通过 MVCC 实现的一种非阻塞读方式。当事务执行 SELECT 查询时，InnoDB 并不会直接读当前最新的数据，而是根据事务开始时生成的 Read View 去判断每条记录的可见性，从而读取符合条件的历史版本。

SQL	是否快照读？	说明
SELECT * FROM t WHERE id=1	✅ 是	快照读
SELECT * FROM t WHERE id=1 FOR UPDATE	❌ 否	当前读，读取最新版本并加锁
UPDATE / DELETE	❌ 否	当前读，必须读取当前版本并加锁
INSERT	❌ 否	写操作，不存在历史版本

1. Java 面试指南（付费）收录的京东面经同学 7 京东到家面试原题：mysql事务隔离级别，默认隔离级别，如何避免幻读
2. Java 面试指南（付费）收录的阿里云面经同学 22 面经：事务隔离级别，幻读和脏读的区别，如何防止幻读，事务的mvcc机制

memo：2025 年 4 月 18 日修改至此，今天有球友发帖说拿到了蚂蚁的暑期实习 offer，问前景怎么样，我只能说蚂蚁作为阿里的嫡长子，一直处在战略发展的核心位置，肯定是值得去的。

65.🌟MVCC 了解吗？

MVCC 指的是多版本并发控制，每次修改数据时，都会生成一个新的版本，而不是直接在原有数据上进行修改。并且每个事务只能看到在它开始之前已经提交的数据版本。

这样的话，读操作就不会阻塞写操作，写操作也不会阻塞读操作，从而避免加锁带来的性能损耗。

其底层实现主要依赖于 Undo Log 和 Read View。

每次修改数据前，先将记录拷贝到Undo Log，并且每条记录会包含三个隐藏列，DB_TRX_ID 用来记录修改该行的事务 ID，DB_ROLL_PTR 用来指向 Undo Log 中的前一个版本，DB_ROW_ID 用来唯一标识该行数据（仅无主键时生成）。

每次读取数据时，都会生成一个 ReadView，其中记录了当前活跃事务的 ID 集合、最小事务 ID、最大事务 ID 等信息，通过与 DB_TRX_ID 进行对比，判断当前事务是否可以看到该数据版本。

请详细说说什么是版本链？

版本链是指 InnoDB 中同一条记录的多个历史版本，通过 DB_ROLL_PTR 字段将它们像链表一样串起来，用来支持 MVCC 的快照读。

假设有一张hero表，表中有这样一行记录，name 为张三，city 为帝都，插入这行记录的事务 id 是 80。

此时，DB_TRX_ID的值就是 80，DB_ROLL_PTR的值就是指向这条 insert undo 日志的指针。

接下来，如果有两个DB_TRX_ID分别为100、200的事务对这条记录进行了update操作，那么这条记录的版本链就会变成下面这样：

也就是说，当更新一行数据时，InnoDB 不会直接覆盖原有数据，而是创建一个新的数据版本，并更新 DB_TRX_ID 和 DB_ROLL_PTR，使它们指向前一个版本和相关的 undo 日志。

这样，老版本的数据就不会丢失，可以通过版本链找到。

由于 undo 日志会记录每一次的 update，并且新插入的行数据会记录上一条 undo 日志的指针，所以可以通过 DB_ROLL_PTR 这个指针找到上一条记录，这样就形成了一个版本链。

请详细说说什么是ReadView？

ReadView 是 InnoDB 为每个事务创建的一份“可见性视图”，用于判断在执行快照读时，哪些数据版本是当前这个事务可以看到的，哪些不能看到。

当事务开始执行时，InnoDB 会为该事务创建一个 ReadView，这个 ReadView 会记录 4 个重要的信息：

• creator_trx_id：创建该 ReadView 的事务 ID。
• m_ids：所有活跃事务的 ID 列表，活跃事务是指那些已经开始但尚未提交的事务。
• min_trx_id：所有活跃事务中最小的事务 ID。它是 m_ids 数组中最小的事务 ID。
• max_trx_id ：事务 ID 的最大值加一。换句话说，它是下一个将要生成的事务 ID。

ReadView 是如何判断记录的某个版本是否可见的？

会通过三个步骤来判断：

①、如果某个数据版本的 DB_TRX_ID 小于 min_trx_id，则该数据版本在生成 ReadView 之前就已经提交，因此对当前事务是可见的。

②、如果 DB_TRX_ID 大于 max_trx_id，则表示创建该数据版本的事务在生成 ReadView 之后开始，因此对当前事务不可见。

③、如果 DB_TRX_ID 在 min_trx_id 和 max_trx_id 之间，需要判断 DB_TRX_ID 是否在 m_ids 列表中：

• 不在，表示创建该数据版本的事务在生成 ReadView 之后已经提交，因此对当前事务也是可见的。
• 在，表示事务仍然活跃，或者在当前事务生成 ReadView 之后才开始，因此是不可见的。

举个实际的例子。

读事务开启了一个 ReadView，这个 ReadView 里面记录了当前活跃事务的 ID 列表（444、555、665），以及最小事务 ID（444）和最大事务 ID（666）。当然还有自己的事务 ID 520，也就是 creator_trx_id。

它要读的这行数据的写事务 ID 是 x，也就是 DB_TRX_ID。

• 如果 x = 110，显然在 ReadView 生成之前就提交了，所以这行数据是可见的。
• 如果 x = 667，显然是未知世界，所以这行数据对读操作是不可见的。
• 如果 x = 519，虽然 519 大于 444 小于 666，但是 519 不在活跃事务列表里，所以这行数据是可见的。因为 519 是在 520 生成 ReadView 之前就提交了。
• 如果 x = 555，虽然 555 大于 444 小于 666，但是 555 在活跃事务列表里，所以这行数据是不可见的。因为 555 不确定有没有提交。

可重复读和读已提交在 ReadView 上的区别是什么？

可重复读：在第一次读取数据时生成一个 ReadView，这个 ReadView 会一直保持到事务结束，这样可以保证在事务中多次读取同一行数据时，读取到的数据是一致的。

读已提交：每次读取数据前都生成一个 ReadView，这样就能保证每次读取的数据都是最新的。

推荐阅读：搞懂Mysql之InnoDB MVCC

如果两个 AB 事务并发修改一个变量，那么 A 读到的值是什么，怎么分析。

事务 A 在读取时是否能读到事务 B 的修改，取决于 A 是快照读还是当前读。如果是快照读，InnoDB 会使用 MVCC 的 ReadView 判断记录版本是否可见，若事务 B 尚未提交或在 A 的视图不可见，则 A 会读到旧值；如果是当前读，则需要加锁，若 B 已提交可直接读取，否则 A 会阻塞直到 B 结束。

1. Java 面试指南（付费）收录的美团面经同学 2 Java 后端技术一面面试原题：说说 MVCC，解决了什么问题？
2. Java 面试指南（付费）收录的小公司面经合集同学 1 Java 后端面试原题：了解的 MVCC 吗？
3. Java 面试指南（付费）收录的联想面经同学 7 面试原题：Mysql 四个隔离级别，MVCC 实现，如果两个AB事务并发修改一个变量，那么A读到的值是什么，怎么分析，快照读的原理，读已提交和可重复读区别，具体原理是什么。
4. Java 面试指南（付费）收录的oppo 面经同学 8 后端开发秋招一面面试原题：讲讲Mysql的MVCC机制
5. Java 面试指南（付费）收录的快手同学 2 一面面试原题：事务隔离级别？MVCC机制介绍下？（版本链）版本链通过什么控制
6. Java 面试指南（付费）收录的美团面经同学 15 点评后端技术面试原题：问了一下mysql的锁和MVCC

memo：2025 年 4 月 19 日修改至此，今天有球友发帖说拿到了拼多多的 offer，这下真的是圆满了。

高可用

66.MySQL数据库读写分离了解吗？

读写分离就是把“写操作”交给主库处理，“读操作”分给多个从库处理，从而提升系统并发性能。

应用层通过中间件（如 MyCat、ShardingSphere）自动路由请求，将 INSERT / UPDATE / DELETE 等写操作发送给主库，将 SELECT 查询操作发送给从库。

// 示例：Java中通过不同数据源切换
@Transactional
public void updateOrder(Order order) {
    masterDataSource.update(order); // 写操作走主库
}

public Order getOrderById(Long id) {
    return slaveDataSource.query(id); // 读操作走从库
}

主库将数据变更通过 binlog 同步到从库，从而保持数据一致性。

主库 dump_thread 线程通过 TCP 将 binlog 推送给从库，从库 io_thread 线程，接收主库 binlog，写入 relay log，从库 sql_thread 线程读取 relay log，并顺序执行 SQL 语句，更新从库数据。

67.读写分离的实现方式有哪些？

实现读写分离有三种方式：最简单的是在应用层手动控制主从数据源，适用于小型项目；

中等项目是通过 Spring + 多数据源插件、AOP 注解自动路由；

大型系统通常使用中间件，如 ShardingSphere、MyCat，支持自动路由、负载均衡、故障转移等功能。

Mycat 的读写分离功能依赖于 MySQL 的主从复制架构：

• writeHost: 表示主节点，负责处理所有的 DML SQL 语句，如 INSERT、UPDATE 和 DELETE。
• readHost: 表示从节点，负责处理查询 SQL 语句（如 SELECT），以实现读写分离。

正常情况下，Mycat 会将第一个配置的 writeHost 作为默认的写节点。所有的 DML SQL 语句会被发送到此默认写节点执行。

写节点完成数据写入后，通过 MySQL 的主从复制机制，将数据同步到所有从节点，确保主从数据一致性。

68.主从复制原理了解吗？

MySQL 的主从复制是一种数据同步机制，用于将数据从主数据库复制到一个或多个从数据库。

主库执行事务提交时，将数据变更以事件形式记录到 Binlog。从库通过 I/O 线程从主库的 Binlog 中读取变更事件，并将这些事件写入到本地的中继日志文件中，SQL 线程会实时监控中继日志的内容，按顺序读取并执行这些事件，从而保证从库与主库数据一致。

1. Java 面试指南（付费）收录的腾讯云智面经同学 16 一面面试原题：MySQL 的主从复制过程

69.主从同步延迟怎么处理？

主从同步延迟是因为从库需要先接收 binlog，再执行 SQL 才能同步主库数据，在高并发写或网络抖动时容易出现延迟，导致读写不一致。

第一种解决方案：对一致性要求高的查询（如支付结果查询）可以直接走主库。

// 伪代码示例
public Object query(String sql) {
    if(isWriteQuery(sql) || needStrongConsistency(sql)) {
        return masterDataSource.query(sql);
    } else {
        return slaveDataSource.query(sql);
    }
}

第二种解决方案：对于非关键业务允许短暂数据不一致，可以提示用户“数据同步中，请稍后刷新”，然后借助异步通知机制替代实时查询。

// 伪代码示例
public Object query(String sql) {
    if(isWriteQuery(sql)) {
        return masterDataSource.query(sql);
    } else {
        // 异步通知用户数据已更新
        notifyUser("数据同步中，请稍后刷新");
        return slaveDataSource.query(sql);
    }
}

第三种解决方案：采用半同步复制，主库在事务提交时，要等至少一个从库确认收到 binlog（但不要求执行完成），才算提交成功。

请说说半同步复制的流程？

第一步，主库安装半同步插件：

INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';

第二步，主库启用半同步复制并设置超时时间：

SET GLOBAL rpl_semi_sync_master_enabled = 1;
SET GLOBAL rpl_semi_sync_master_timeout = 10000;

主库 my.cnf 配置示例：

[mysqld]
plugin-load = "rpl_semi_sync_master=semisync_master.so"
rpl_semi_sync_master_enabled = 1
rpl_semi_sync_master_timeout = 10000
# MySQL 5.7+建议使用无损模式
rpl_semi_sync_master_wait_point = AFTER_SYNC

第三步，从库安装半同步插件：

INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

第四步，从库启用半同步复制：

SET GLOBAL rpl_semi_sync_slave_enabled = 1;

从库 my.cnf 配置示例：

[mysqld]
plugin-load = "rpl_semi_sync_slave=semisync_slave.so"
rpl_semi_sync_slave_enabled = 1

memo：2025 年 4 月 20 日修改至此，今天给球友修改简历时，碰到有球友说，把星球安利给了同门，进来后都说好，口碑+1，很欣慰呢。

70.🌟你们一般是怎么分库的呢？

分库的策略有两种，第一种是垂直分库：按照业务模块将不同的表拆分到不同的库中，比如说用户、登录、权限等表放在用户库中，商品、分类、库存放在商品库中，优惠券、满减、秒杀放在活动库中。

第二种是水平分库：按照一定的策略将一个表中的数据拆分到多个库中，比如哈希分片和范围分片，对用户 id 进行取模运算或者范围划分，将数据分散到不同的库中。

贴一段使用 ShardingSphere 的 inline 算法定义分片规则：

rules:
- !SHARDING
  tables:
    order:
      actualDataNodes: db_${0..3}.order_${0..15}
      databaseStrategy:
        standard:
          shardingColumn: user_id
          shardingAlgorithmName: db_hash_mod
      tableStrategy:
        standard:
          shardingColumn: order_time
          shardingAlgorithmName: table_interval_yearly
  shardingAlgorithms:
    db_hash_mod:
      type: HASH_MOD
      props:
        sharding-count: 4
    table_interval_yearly:
      type: INTERVAL
      props:
        datetime-pattern: 'yyyy-MM-dd HH:mm:ss'
        datetime-lower: '2024-01-01 00:00:00'
        datetime-upper: '2025-01-01 00:00:00'
        sharding-suffix-pattern: 'yyyy'
        datetime-interval-amount: 1
        datetime-interval-unit: 'Years'

1. Java 面试指南（付费）收录的快手面经同学 7 Java 后端技术一面面试原题：分库分表了解吗
2. Java 面试指南（付费）收录的华为面经同学 8 技术二面面试原题：说说分库分表的准则

71.🌟那你们是怎么分表的？

当单表超过 500 万条数据，就可以考虑水平分表了。比如说我们可以将文章表拆分成多个表，如 article_0、article_9999、article_19999 等。

在技术派实战项目中，我们将文章的基本信息和内容详情做了垂直分表处理，因为文章的内容会占用比较大的空间，在只需要查看文章基本信息时把文章详情也带出来的话，就会占用更多的网络 IO 和内存导致查询变慢；而文章的基本信息，如标题、作者、状态等信息占用的空间较小，很适合不需要查询文章详情的场景。

1. Java 面试指南（付费）收录的快手面经同学 7 Java 后端技术一面面试原题：分库分表了解吗
2. Java 面试指南（付费）收录的华为面经同学 8 技术二面面试原题：说说分库分表的准则
3. Java 面试指南（付费）收录的腾讯面经同学 29 Java 后端一面原题：表存满了之后怎么扩表？

72.水平分库分表的分片策略有哪几种？

常见的分片策略有三种，范围分片、Hash 分片和路由分片。

范围分片是根据某个字段的值范围进行水平拆分。适用于分片键具有连续性的场景。

比如说将 user_id 作为分片键：

• 1 ~ 10000 → db1.user_1
• 10001 ~ 20000 → db2.user_2

Hash 分片是指通过对分片键的值进行哈希取模，将数据均匀分布到多个库表中，适用于分片键具有离散性的场景。

比如说我们一开始规划好了 4 个表，那么就可以简单地通过取模来实现分表：

public String getTableNameByHash(long userId) {
    int tableIndex = (int) (userId % 4);
    return "user_" + tableIndex;
}

路由分片是通过路由配置来确定数据应该存储在哪个库表，适用于分片键不规律的场景。

比如说我们可以通过 order_router 表来确定订单数据存储在哪个表中：

order_id	table_id
xxxx	table_1
yyyy	table_2
zzzz	table_3

1. Java 面试指南（付费）收录的腾讯面经同学 24 面试原题：项目中的水平分表是怎么做的？分片键具体是怎么设置的？
2. Java 面试指南（付费）收录的腾讯面经同学 29 Java 后端一面原题：分库分表具体的分片策略是怎么做的？

memo：2025 年 4 月 22 日修改至此，今天给拿到蚂蚁暑期实习的球友发了个红包，感谢他在星球的经验贴，这些精华帖也会帮助到下一届的球友们，真的非常感谢。

73.不停机扩容怎么实现？

第一个阶段：新旧库同时写入，确保数据实时同步；可以借助消息队列实现异步补偿，幂等避免重复写入。读操作仍然走旧库。

代码参考：

@Transactional
public void createOrder(Order order) {
    oldDB.insert(order);  // 写入旧库
    newDB.insert(order);  // 写入新扩容节点
    kafka.send("data_sync", order);  // 异步补偿通道
}

第二个阶段，通过 Canal 或者自研脚本将旧库的历史数据同步到新库。关键业务在查询时同时查询新旧库，进行数据校验，确保一致性。

public List<Order> getOrders(Long userId) {
    List<Order> orders = newDB.getOrders(userId);
    List<Order> oldOrders = oldDB.getOrders(userId);
    if (!orders.equals(oldOrders)) {
        // 数据不一致，进行补偿
        kafka.send("data_sync", oldOrders);
    }
}

第三个阶段，在确认新库数据一致性后，逐步将读请求切换到新库，然后下线旧库。

74.常用的分库分表中间件有哪些？

常用的分库分表中间件有 ShardingSphere 和 Mycat。

①、ShardingSphere 最初由当当开源，后来贡献给了 Apache，其子项目 Sharding-JDBC 主要在 Java 的 JDBC 层提供额外的服务。无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。

②、Mycat 是由阿里巴巴的一款产品 Cobar 衍生而来，可以把它看作一个数据库代理。

推荐阅读：mycat 介绍

75.你觉得分库分表会带来什么问题呢？

第一，跨库事务无法依赖单机 MySQL 的 ACID 特性，需要使用分布式事务解决方案，如 Seata 的 AT 模式、TCC 模式等。

第二，跨库后无法使用 JOIN 联表查询。可以在业务层进行拼接，或者把需要联表查询的数据放到 ES 中。

// Java 代码示例
User user = userService.getUserById(1);
List<Order> orders = orderService.getOrdersByUserId(1);

第三，自增 ID 在分片场景下容易冲突，需要使用全局唯一方案。

数据库表被切分后，不能再依赖数据库自身的主键生成机制，所以需要一些手段来保证全局主键唯一。比如说雪花算法、京东的 JD-hotkey。

你们项目中的分布式主键 id 是怎么生成的？

在技术派项目中，我们在雪花算法的基础上实现了一套自定义的 ID 生成方案，通过更改时间戳单位、ID 长度、workId 与 dataCenterId 的分配比例，ID 生成的延迟降低了 20%；满足了分布式环境下 ID 的唯一性。

雪花算法具体是怎么实现的？

雪花算法是 Twitter 开源的分布式 ID 生成算法，其核心思想是：使用一个 64 位的数字来作为全局唯一 ID。

• 第 1 位是符号位，永远是 0，表示正数。
• 接下来的 41 位是时间戳，记录的是当前时间戳减去一个固定的开始时间戳，可以使用 69 年。
• 然后是 10 位的工作机器 ID。
• 最后是 12 位的序列号，每毫秒最多可生成 4096 个 ID。

大致的实现代码如下所示：

public class SnowflakeIdGenerator {
    private long datacenterId = 1L; // 数据中心ID
    private long machineId = 1L; // 机器ID
    private long sequence = 0L; // 序列号

    private long lastTimestamp = -1L;

    public synchronized long nextId() {
        long timestamp = System.currentTimeMillis();
        if (timestamp == lastTimestamp) {
            sequence = (sequence + 1) & 4095;
            if (sequence == 0) {
                while (timestamp == lastTimestamp) {
                    timestamp = System.currentTimeMillis();
                }
            }
        } else {
            sequence = 0;
        }

        lastTimestamp = timestamp;

        return ((timestamp - 1609459200000L) << 22) | (datacenterId << 17) | (machineId << 12) | sequence;
    }
}

1. Java 面试指南（付费）收录的腾讯面经同学 29 Java 后端一面原题：id是怎么生成的？（分布式自增主键）

memo：2025 年 4 月 23 日修改至此，今天有球友反馈说拿到了 vivo 的 offer，也是他第一个暑期实习 offer，真的需要恭喜啦🎉。

运维

76.百万级别以上的数据如何删除？

在处理百万级别的数据删除时，大范围的 DELETE 语句往往会造成锁表时间长、事务日志膨胀等问题。

可以采用批量删除的方案，将删除操作分成多个小批次进行处理。

public void batchDelete(String tableName, String condition, int batchSize) {
    // 1. 创建线程池
    int threadCount = Runtime.getRuntime().availableProcessors();
    ExecutorService executor = Executors.newFixedThreadPool(threadCount);
    CountDownLatch latch = new CountDownLatch(threadCount);

    // 2. 获取总记录数
    long totalCount = getTotalCount(tableName, condition);
    
    // 3. 计算每个线程处理的数据量
    long perThreadCount = totalCount / threadCount;
    
    // 4. 分配任务给线程池
    for (int i = 0; i < threadCount; i++) {
        long startId = i * perThreadCount;
        long endId = (i == threadCount - 1) ? totalCount : (startId + perThreadCount);
        
        executor.execute(() -> {
            try {
                // 分批次删除数据
                for (long j = startId; j < endId; j += batchSize) {
                    String deleteSql = String.format(
                        "DELETE FROM %s WHERE %s LIMIT %d",
                        tableName, condition, batchSize
                    );
                    // 执行删除
                    jdbcTemplate.update(deleteSql);
                }
            } finally {
                latch.countDown();
            }
        });
    }
    
    // 5. 等待所有线程完成
    latch.await();
    executor.shutdown();
}

也可以采用创建新表替换原表的方式，把需要保留的数据迁移到新表中，然后删除旧表。

简单的方案：

-- 1. 创建新表结构(包含索引)
CREATE TABLE new_table LIKE large_table;

-- 2. 插入需要保留的数据
INSERT INTO new_table 
SELECT * FROM large_table WHERE condition;

-- 3. 重命名表
RENAME TABLE large_table TO old_table, new_table TO large_table;

-- 4. 删除旧表
DROP TABLE old_table;

加入检查表空间、分批导入数据、验证数据一致性等步骤：

-- 1. 在执行之前先检查空间是否足够
SELECT table_schema, 
       table_name, 
       round(((data_length + index_length) / 1024 / 1024), 2) "Size in MB"
FROM information_schema.TABLES 
WHERE table_schema = DATABASE()
AND table_name = 'large_table';

-- 2. 创建新表
CREATE TABLE new_table LIKE large_table;

-- 3. 分批导入数据（避免一次性导入过多数据）
SET @batch = 1;
SET @batch_size = 10000;
SET @total = (SELECT COUNT(*) FROM large_table WHERE condition);

REPEAT
    INSERT INTO new_table 
    SELECT * FROM large_table 
    WHERE condition
    LIMIT @batch_size;
    
    SET @batch = @batch + 1;
UNTIL @batch * @batch_size > @total END REPEAT;

-- 4. 验证数据一致性
SELECT COUNT(*) FROM new_table;
SELECT COUNT(*) FROM large_table WHERE condition;

-- 5. 在业务低峰期执行表切换
RENAME TABLE large_table TO old_table, 
             new_table TO large_table;

-- 6. 确认无误后再删除旧表（建议不要立即删除）
-- DROP TABLE old_table;

77.千万级大表如何添加字段？

在低版本的 MySQL 中，千万级数据量的表中添加字段时，直接使用 ALTER TABLE 命令会导致长时间锁表、甚至数据库崩溃等。

可以使用 Percona Toolkit 的 pt-online-schema-change 来完成，它通过创建临时表、逐步同步数据并使用触发器捕获变更来实现。

pt-online-schema-change --alter "ADD COLUMN new_column datatype" D=database,t=your_table --execute

对于 MySQL 8.0+ 版本，可以直接通过 ALTER TABLE 来完成，因为加入了 INSTAN 算法，添加列并不会长时间锁表。

ALTER TABLE your_table ADD COLUMN new_column datatype;

如果没有指定 ALGORITHM=INSTANT 算法，MySQL 会先尝试 INSTANT 算法；如果无法完成，会切换到 INPLACE 算法；如果仍然无法完成，会尝试 COPY 算法。

78.MySQL 导致 cpu 飙升的话，要怎么处理呢？

我通常先通过 top 命令确认是否是 mysqld 的进程占用。

然后通过 SHOW PROCESSLIST 和慢查询日志定位是否存在耗时 SQL，再配合 explain 和 performance_schema 分析 SQL 是否命中索引，是否存在临时表和排序。

-- 使用 EXPLAIN 分析SQL执行计划
EXPLAIN SELECT * FROM large_table WHERE condition;

-- 查看表的索引使用情况
SHOW INDEX FROM table_name;

-- 查看InnoDB状态
SHOW ENGINE INNODB STATUS;

-- 查看表的统计信息
ANALYZE TABLE table_name;

最终通过 SQL 优化、加索引、分批操作等手段逐步优化。

memo：2025 年 4 月 24 日修改至此，今天有球友反馈说拿到了小鹏汽车测试岗的 offer，真的恭喜啦🎉。

SQL 题

79.一张表：id，name，age，sex，class，sql 语句：所有年龄为 18 的人的名字？找到每个班年龄大于 18 有多少人？找到每个班年龄排前两名的人？（补充）

建议大家在本地建表，实操一下。 2024 年 04 月 11 日增补。

第一步，建表：

CREATE TABLE students (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(50),
    age INT,
    sex CHAR(1),
    class VARCHAR(50)
);

第二步，插入数据：

INSERT INTO students (name, age, sex, class) VALUES
('沉默王二', 18, '女', '三年二班'),
('沉默王一', 20, '男', '三年二班'),
('沉默王三', 19, '男', '三年三班'),
('沉默王四', 17, '男', '三年三班'),
('沉默王五', 20, '女', '三年四班'),
('沉默王六', 21, '男', '三年四班'),
('沉默王七', 18, '女', '三年四班');

所有年龄为 18 的人的名字？

SELECT name FROM students WHERE age = 18;

这条 SQL 语句从表中选择age等于 18 的所有记录，并返回这些记录的name字段。

如果可以的话，可以给 age 字段加上索引。

ALTER TABLE students ADD INDEX age_index (age);

找到每个班年龄大于 18 有多少人?

SELECT class, COUNT(*) AS number_of_students
FROM students
WHERE age > 18
GROUP BY class;

这条 SQL 语句先筛选出年龄大于 18 的记录，然后按class分组，并通过 count 统计每个班的学生数。

找到每个班年龄排前两名的人？

这个查询稍微复杂一些，需要使用子查询和去重 DISTINCT。

SELECT a.class, a.name, a.age
FROM students a
WHERE (
    SELECT COUNT(DISTINCT b.age)
    FROM students b
    WHERE b.class = a.class AND b.age > a.age
) < 2
ORDER BY a.class, a.age DESC;

这条 SQL 语句首先从students表中选择class、name和age字段，然后使用子查询计算每个班级中年龄排前两名的学生。

1. Java 面试指南（付费）收录的奇安信面经同学 1 Java 技术一面面试原题：一张表：id，name，age，sex，class，sql 语句：所有年龄为 18 的人的名字？找到每个班年龄大于 18 有多少人？找到每个班年龄排前两名的人？

80.有一个查询需求，MySQL 中有两个表，一个表 1000W 数据，另一个表只有几千数据，要做一个关联查询，如何优化

第一步，为关联字段建立索引，确保 on 连接的字段都有索引。

ALTER TABLE big_table ADD INDEX idx_small_id(small_id);

第二步，小表驱动大表，将小表放在 JOIN 的左边（驱动表），大表放在右边。

SELECT ... FROM small_table s 
JOIN big_table b ON s.id = b.small_id

1. Java 面试指南（付费）收录的京东面经同学 1 Java 技术一面面试原题：有一个查询需求，MySQL 中有两个表，一个表 1000W 数据，另一个表只有几千数据，要做一个关联查询，如何优化

81.新建一个表结构，创建索引，将百万或千万级的数据使用 insert 导入该表，新建一个表结构，将百万或千万级的数据使用 isnert 导入该表，再创建索引，这两种效率哪个高呢？或者说用时短呢？

先说结论：

在大数据量导入场景下，先导入数据，后建索引的效率显著高于先建索引，后导入数据的效率。

来，实操。

先创建一个表，然后创建索引，执行插入语句，来看看执行时间（100 万数据在我本机上执行时间比较长，我们就用 10 万条数据来测试）。

CREATE TABLE test_table (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    email VARCHAR(255) NOT NULL,
    created_at DATETIME NOT NULL
);
CREATE INDEX idx_name ON test_table(name);
DELIMITER //

CREATE PROCEDURE insert_data()
BEGIN
    DECLARE i INT DEFAULT 0;

    WHILE i < 1000000 DO
        INSERT INTO test_table(name, email, created_at)
        VALUES (CONCAT('wanger',i), CONCAT('email', i, '@example.com'), NOW());
        SET i = i + 1;
    END WHILE;
END //

DELIMITER ;
CALL insert_data();

总的时间 13.93+0.01+0.01+0.01=13.96 秒。

接下来，我们再创建一个表，执行插入操作，然后创建索引。

CREATE TABLE test_table_no_index (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    email VARCHAR(255) NOT NULL,
    created_at DATETIME NOT NULL
);
DELIMITER //

CREATE PROCEDURE insert_data_no_index()
BEGIN
    DECLARE i INT DEFAULT 0;

    WHILE i < 1000000 DO
        INSERT INTO test_table_no_index(name, email, created_at)
        VALUES (CONCAT('wanger', i), CONCAT('email', i, '@example.com'), NOW());
        SET i = i + 1;
    END WHILE;
END //

DELIMITER ;
CALL insert_data_no_index();
CREATE INDEX idx_name_no_index ON test_table_no_index(name);

来看一下总的时间，0.01+0.00+13.08+0.18=13.27 秒。

先插入数据再创建索引的方式比先创建索引再插入数据要快一点。

然后时间差距很微小，主要是因为我们插入的数据少。说一下差别。

• 先插入数据再创建索引：在没有索引的情况下插入数据，数据库不需要在每次插入时更新索引。
• 先创建索引再插入数据：数据库需要在每次插入新记录时维护索引结构，随着数据量的增加，索引的维护会导致额外的性能开销。

MySQL是先建立索引好还是先插入数据好？

如果是小批量插入，可以先建索引；但在大数据量数据导入场景下，推荐先插入数据再建索引。

因为索引是基于 B+ 树的，大量插入时如果提前建索引，会频繁触发页分裂和索引结构调整，影响性能。

插入完成后统一构建索引，MySQL 会按顺序批量生成索引结构，速度更快、资源消耗更低。

1. Java 面试指南（付费）收录的农业银行面经同学 7 Java 后端面试原题：数据库是先建立索引还是先插入数据

memo：2025 年 4 月 25 日修改至此，今天有家长发来感谢信，说孩子在加入星球后，整个人明显变得更加积极了。说真的，家长的认可，更让我感到虚荣心得到了极大的满足。

82.什么是深分页，select * from tbn limit 1000000000 这个有什么问题，如果表大或者表小分别什么问题

深分页是指在 MySQL 中获取比较靠后的数据页，比如第 1000 页、第 10000 页等。特别是使用 LIMIT offset,count 这种方式，当 offset 特别大，就会带来严重的性能问题。

对于 SELECT * FROM tbn LIMIT 1000000,10，这样的查询语句来说，MySQL 会：

• 从表中读取第一条记录，判断是否满足 where 条件；如果满足，计数器+1；否则直到 计数器累计到 1000000 时才开始真正取数据
• 再继续获取 10 条数据，返回

性能会非常差，因为需要从头扫描，无法利用索引优化，并且需要抛弃大量不需要的数据，占用大量的内存和 CPU 资源。

可以借助主键索引分页进行优化：

SELECT * FROM tbn
WHERE id > (SELECT id FROM tbn ORDER BY id LIMIT 1000000, 1)
LIMIT 10

或者记住上次分页的最大 ID，然后再查询：

SELECT * FROM tbn
WHERE id > last_page_max_id
LIMIT 10

1. Java 面试指南（付费）收录的字节跳动面经同学 13 Java 后端二面面试原题：什么是深分页，select * from tbn limit 1000000000 这个有什么问题，如果表大或者表小分别什么问题

83.SQL 题：一个学生成绩表，字段有学生姓名、班级、成绩，求各班前十名

第一步，建表：

CREATE TABLE student_scores (
    student_name VARCHAR(100),
    class VARCHAR(50),
    score INT
);

第二步，插入数据：

INSERT INTO student_scores (student_name, class, score) VALUES
('沉默王二', '三年二班', 88),
('沉默王三', '三年二班', 92),
('沉默王四', '三年二班', 87),
('沉默王五', '三年二班', 85),
('沉默王六', '三年二班', 90),
('沉默王七', '三年二班', 95),
('沉默王八', '三年二班', 82),
('沉默王九', '三年二班', 78),
('沉默王十', '三年二班', 91),
('沉默王十一', '三年二班', 79),
('沉默王十二', '三年三班', 84),
('沉默王十三', '三年三班', 81),
('沉默王十四', '三年三班', 90),
('沉默王十五', '三年三班', 88),
('沉默王十六', '三年三班', 87),
('沉默王十七', '三年三班', 93),
('沉默王十八', '三年三班', 89),
('沉默王十九', '三年三班', 85),
('沉默王二十', '三年三班', 92),
('沉默王二十一', '三年三班', 84);

第三步，查询各班前十名。如果 MySQL 是 8.0 以下版本，不支持窗口函数，可以通过在查询中维护班级当前处理状态和排名，实现分组内按成绩排序并打标号，再取前十名。

SET @cur_class = NULL, @cur_rank = 0;

SELECT student_name, class, score
FROM (
    SELECT
        student_name,
        class,
        score,
        @cur_rank := IF(@cur_class = class, @cur_rank + 1, 1) AS rank,
        @cur_class := class
    FROM student_scores
    ORDER BY class, score DESC
) AS ranked
WHERE ranked.rank <= 10;

步骤	解释
@cur_class 变量	记录当前正在处理的班级
@cur_rank 变量	记录当前班级的排名，默认 0
IF(@cur_class = class, @cur_rank + 1, 1)	如果班级没变，就排名 +1；如果换了新班级，排名从 1 重新开始
@cur_class := class	更新当前班级变量，保持班级变化跟踪
ORDER BY class, score DESC	必须先按班级升序、成绩降序排好，才能保证变量正确打排名
外层 WHERE rank <= 10	只取每班前十名 ✅

如果是 MySQL 8.0+ 版本，可以使用窗口函数来完成：

SELECT student_name, class, score
FROM (
    SELECT 
        student_name, 
        class, 
        score,
        ROW_NUMBER() OVER (PARTITION BY class ORDER BY score DESC) AS rn
    FROM student_scores
) AS tmp
WHERE rn <= 10;

SQL 用到的技术	说明
ROW_NUMBER() OVER (PARTITION BY class ORDER BY score DESC)	给每个班独立打排名，从 1 开始
子查询 tmp	用来临时生成带有 rn（排名）的数据集
外层 WHERE rn <= 10	选出每个班排名前 10 的学生
ORDER BY score DESC	成绩高排前面，符合常规排名逻辑

1. Java 面试指南（付费）收录的腾讯云智面经同学 16 一面面试原题：SQL 题：一个学生成绩表，字段有学生姓名、班级、成绩，求各班前十名

memo：2025 年 4 月 26 日修改至此，今天有球友发邮件送来喜报，说他拿到了蚂蚁国际的 offer，并且多次感谢星球对他实习的帮助，比身边朋友拿到了更多的面试机会，并且准备阶段只看二哥的专栏，都有一种精神洁癖了，说实话，这种喜报我真的爱看，😄。

---

整整两个月，面渣逆袭 MySQL 篇第二版终于整理完了，这一版几乎可以说是重写了，每天耗费了大量的精力在上面，可以说是改头换面，有一种士别俩月，当刮目相看的感觉。

网上的八股其实不少，有些还是付费的，我觉得是一件好事，可以给大家提供更多的选择，但面渣逆袭的含金量懂的都懂。

面渣逆袭第二版是在星球嘉宾三分恶的初版基础上，加入了二哥自己的思考，加入了 1000 多份真实面经之后的结果，并且从 24 届到 25 届，再到 26 届，帮助了很多小伙伴。未来的 27、28 届，也将因此受益，从而拿到心仪的 offer。

能帮助到大家，我很欣慰，并且在重制面渣逆袭的过程中，我也成长了很多，很多薄弱的基础环节都得到了加强，因此第二版的面渣逆袭不只是给大家的礼物，也是我在技术上蜕变的记录。

很多时候，我觉得自己是一个佛系的人，不愿意和别人争个高低，也不愿意去刻意宣传自己的作品。

我喜欢静待花开。

如果你觉得面渣逆袭还不错，可以告诉学弟学妹们有这样一份免费的学习资料，帮我做个口碑。

我还会继续优化，也不确定第三版什么时候会来，但我会尽力。

愿大家都有一个光明的未来。

由于 PDF 没办法自我更新，所以需要最新版的小伙伴，可以微信搜【沉默王二】，或者扫描/长按识别下面的二维码，关注二哥的公众号，回复【222】即可拉取最新版本。

当然了，请允许我的一点点私心，那就是星球的 PDF 版本会比公众号早一个月时间，毕竟星球用户都付费过了，我有必要让他们先享受到一点点福利。相信大家也都能理解，毕竟在线版是免费的，CDN、服务器、域名、OSS 等等都是需要成本的。

更别说我付出的时间和精力了，大家觉得有帮助还请给个口碑，让你身边的同事、同学都能受益到。

我把二哥的 Java 进阶之路、JVM 进阶之路、并发编程进阶之路，以及所有面渣逆袭的版本都放进来了，涵盖 Java基础、Java集合、Java并发、JVM、Spring、MyBatis、计算机网络、操作系统、MySQL、Redis、RocketMQ、分布式、微服务、设计模式、Linux 等 16 个大的主题，共有 40 多万字，2000+张手绘图，可以说是诚意满满。

这次仍然是三个版本，亮白、暗黑和 epub 版本。给大家展示其中一个 epub 版本吧，有些小伙伴很急需这个版本，所以也满足大家了。

---

图文详解 83 道 MySQL 面试高频题，这次吊打面试官，我觉得稳了（手动 dog）。整理：沉默王二，戳转载链接，作者：三分恶，戳原文链接。

没有什么使我停留——除了目的，纵然岸旁有玫瑰、有绿荫、有宁静的港湾，我是不系之舟。

系列内容：

• 面渣逆袭 Java SE 篇 👍
• 面渣逆袭 Java 集合框架篇 👍
• 面渣逆袭 Java 并发编程篇 👍
• 面渣逆袭 JVM 篇 👍
• 面渣逆袭 Spring 篇 👍
• 面渣逆袭 Redis 篇 👍
• 面渣逆袭 MyBatis 篇 👍
• 面渣逆袭 MySQL 篇 👍
• 面渣逆袭操作系统篇 👍
• 面渣逆袭计算机网络篇 👍
• 面渣逆袭 RocketMQ 篇 👍
• 面渣逆袭分布式篇 👍
• 面渣逆袭微服务篇 👍
• 面渣逆袭设计模式篇 👍