1、【Java面试】这一次彻底带你搞懂，Mysql的事务隔离级别_哔哩哔哩_bilibili
# MySQL事务隔离级别深度解析：从脏读到幻读的完整理解
## 引言
一个工作了六年的粉丝去阿里面试，在第一面的时候被问到MySQL事务**隔离级别**的一个问题。他竟然没有回答上来，一直在私信我向我诉苦。我只能安慰他，我说以后还有机会的，慢慢来。
关于这个问题，我们来看看普通人和高手的回答。
## 一、普通人的回答
**普通人的回答：**
MySQL的事务隔离级别，它有四种。第一种是**读已提交**。第二个是**可重复读**。第三个是**串行化**。第四个是**读未提交**。
这四种隔离级别代表的是我在不同的那个就是我多。如果我发生**事务竞争**的时候，那么我每一个事务**并发执行**的时候，我对数据的影响，比如说事务之间的隔离性，所以通过不同的隔离级别，它可以去解决所谓的**幻读**，或者**不可重复读**，以及说**读未提交**，这样一些问题。
然后我记得就是，最安全的是那种**串行化**，串行化就是说它不会存在任何的幻读、不可重复读的一些问题。
**问题分析：**
普通人的回答主要存在以下问题：
- 只是简单列举了四种隔离级别，没有深入理解
- 没有说明为什么需要隔离级别
- 没有解释三种并发问题（脏读、不可重复读、幻读）
- 没有说明不同隔离级别如何解决这些问题
- 没有提到MySQL InnoDB的默认隔离级别
## 二、高手的回答
### 2.1 并发问题概述
**高手的回答：**
**总体来说呢，多个事务并发可能会产生三种不同的一个现象。**
在理解隔离级别之前，我们需要先理解并发事务可能产生的问题。
### 2.2 问题一：脏读（Dirty Read）
**第一个，假设有两个事务，T1和T2同时在执行。**
那么T1事务有可能会读取到T2事务**未提交**的数据。但是未提交的事务T2有可能会**最终回滚**，也就导致T1事务读取到一个最终不一定存在的数据，从而产生一个**脏读**的现象。
**脏读示例：**
```
时间线：
T1: 事务A读取账户余额（余额=1000）
T2: 事务B修改账户余额（余额=2000，未提交）
T3: 事务A再次读取账户余额（余额=2000，读取到未提交的数据）
T4: 事务B回滚（余额恢复为1000）
结果：事务A读取到了不存在的数据（脏数据）
```
**问题影响：**
- 读取到未提交的数据
- 如果该事务回滚，读取的数据就是错误的
- 可能导致业务逻辑错误
### 2.3 问题二：不可重复读（Non-Repeatable Read）
**第二个是说，假设两个事务T1、T2同时在执行。**
那么事务T1在不同的时刻读取的同一行数据的时候，有可能结果会不一样，主要导致一个**不可重复读**的一个问题。
**不可重复读示例：**
```
时间线：
T1: 事务A读取账户余额（余额=1000）
T2: 事务B修改账户余额并提交（余额=2000）
T3: 事务A再次读取账户余额（余额=2000，与第一次读取不一致）
结果：事务A在同一个事务中，两次读取同一数据结果不一致
```
**问题影响：**
- 在同一个事务中，多次读取同一数据结果不一致
- 可能导致业务逻辑判断错误
- 影响事务的一致性
### 2.4 问题三：幻读（Phantom Read）
**第三个是说，假设有两个事务T1、T2同时在执行。**
那么事务T1在执行范围查询或者范围修改一个时候，事务T2插入了一条属于事务T1范围内的数据，并且**提交**。
那么这个时候，事务T1**查询**的时候发现多出了一条数据，或者说T1事务发现这条数据并没有被修改。那么看起来像是产生了一个幻觉，这种现象我们称为**幻读**。
**幻读示例：**
```
时间线：
T1: 事务A查询年龄>30的用户（返回3条记录）
T2: 事务B插入一条年龄=35的用户记录并提交
T3: 事务A再次查询年龄>30的用户（返回4条记录，多了一条）
结果：事务A在同一个事务中，两次范围查询结果不一致
```
**问题影响：**
- 在同一个事务中，范围查询结果不一致
- 可能导致统计、计算等业务逻辑错误
- 影响事务的一致性
### 2.5 三种问题对比
| 问题 | 描述 | 示例场景 | 影响 |
|------|------|----------|------|
| 脏读 | 读取到未提交的数据 | 事务A读取事务B未提交的数据 | 可能读取到错误数据 |
| 不可重复读 | 同一事务中多次读取同一数据结果不一致 | 事务A两次读取，中间事务B修改并提交 | 数据不一致 |
| 幻读 | 同一事务中范围查询结果不一致 | 事务A两次范围查询，中间事务B插入并提交 | 结果集不一致 |
## 三、四种隔离级别
而这三种现象在实际应用里面的可能有些场景不能接受某些现象的存在，所以它是一个标准里面的定义了四种隔离级别。
### 3.1 读未提交（Read Uncommitted）
**第一种是读未提交（Read Uncommitted）。**
在这种隔离级别下呢，可能会产生**脏读**、**不可重复读**以及**幻读**。
**特点：**
- 最低的隔离级别
- 事务可以读取到其他事务未提交的数据
- 性能最好，但数据安全性最差
**问题：**
- ✅ 脏读：可能发生
- ✅ 不可重复读：可能发生
- ✅ 幻读：可能发生
### 3.2 读已提交（Read Committed）
**第二种是读已提交（Read Committed）。**
在这种隔离级别下可能会产生**不可重复读**和**幻读**。
**特点：**
- 事务只能读取到其他事务已提交的数据
- 解决了脏读问题
- Oracle数据库的默认隔离级别
**问题：**
- ❌ 脏读：不会发生
- ✅ 不可重复读：可能发生
- ✅ 幻读：可能发生
### 3.3 可重复读（Repeatable Read）
**第三种是可重复读（Repeatable Read）。**
那么在这种隔离级别下可能会产生**幻读**。
**特点：**
- 事务在执行期间，多次读取同一数据结果一致
- 解决了脏读和不可重复读问题
- **MySQL InnoDB引擎的默认隔离级别**
**问题：**
- ❌ 脏读：不会发生
- ❌ 不可重复读：不会发生
- ✅ 幻读：可能发生（但InnoDB通过MVCC和Next-Key Lock基本解决了）
### 3.4 串行化（Serializable）
**第四种是串行化（Serializable）。**
那么在这种隔离级别下呢，多个**并发事务**会**串行化**执行，不会产生任何安全性问题。
**特点：**
- 最高的隔离级别
- 事务串行执行，完全隔离
- 解决了所有并发问题
- 性能最差，但数据安全性最高
**问题：**
- ❌ 脏读：不会发生
- ❌ 不可重复读：不会发生
- ❌ 幻读：不会发生
### 3.5 隔离级别对比表
| 隔离级别 | 脏读 | 不可重复读 | 幻读 | 性能 | 安全性 |
|---------|------|-----------|------|------|--------|
| 读未提交 | ✅ 可能 | ✅ 可能 | ✅ 可能 | 最高 | 最低 |
| 读已提交 | ❌ 不会 | ✅ 可能 | ✅ 可能 | 较高 | 较低 |
| 可重复读 | ❌ 不会 | ❌ 不会 | ⚠️ 可能* | 中等 | 较高 |
| 串行化 | ❌ 不会 | ❌ 不会 | ❌ 不会 | 最低 | 最高 |
*注：MySQL InnoDB在可重复读级别下，通过MVCC和Next-Key Lock基本解决了幻读问题。
## 四、MySQL InnoDB的默认隔离级别
在这四种隔离级别里面呢，只有串行化解决了全部的问题。但也意味着呢，这种**隔离级别**性能是最低的。
在MySQL里面，InnoDB引擎默认的**隔离级别**是**RR（Repeatable Read）**，也就是**可重复读**。因为它需要保证事务ACID特性做的**隔离性**。
### 4.1 为什么选择可重复读？
**原因：**
1. **平衡性能和安全性**：在保证数据安全的同时，性能较好
2. **解决大部分问题**：解决了脏读和不可重复读
3. **MVCC机制**：InnoDB通过MVCC（多版本并发控制）和Next-Key Lock基本解决了幻读问题
### 4.2 查看和设置隔离级别
**查看当前隔离级别：**
```sql
-- 查看全局隔离级别
SELECT @@global.transaction_isolation;
-- 查看当前会话隔离级别
SELECT @@session.transaction_isolation;
-- 或者
SHOW VARIABLES LIKE 'transaction_isolation';
```
**设置隔离级别：**
```sql
-- 设置全局隔离级别
SET GLOBAL transaction_isolation = 'REPEATABLE READ';
-- 设置当前会话隔离级别
SET SESSION transaction_isolation = 'READ COMMITTED';
-- 或者在配置文件中设置
[mysqld]
transaction-isolation = REPEATABLE-READ
```
## 五、实际应用中的注意事项
关于这个问题啊，很多用了MySQL很长时间的程序员都不一定能够回答得很清楚。这其实是非常不正常的，因为虽然啊，InnoDB的默认隔离级别能够去解决90%以上的问题。但是有些公司或者某些业务可能会去修改事务隔离级别。而如果你不去注意或者你不知道，就很可能在程序中出现一些莫名其妙的问题。
### 5.1 常见问题
**问题1：业务场景需要不同的隔离级别**
- **金融支付**：可能需要串行化级别
- **统计查询**：可能使用读已提交级别
- **一般业务**：使用默认的可重复读级别
**问题2：不了解隔离级别导致的问题**
- 在可重复读级别下，可能出现幻读问题
- 在读已提交级别下，可能出现不可重复读问题
- 不了解隔离级别，可能导致业务逻辑错误
**问题3：性能问题**
- 串行化级别性能最差
- 读未提交级别性能最好但安全性最差
- 需要根据业务场景选择合适的隔离级别
### 5.2 最佳实践
1. **了解默认隔离级别**：知道InnoDB默认是可重复读
2. **根据业务选择**：根据业务需求选择合适的隔离级别
3. **测试验证**：修改隔离级别后，要充分测试
4. **监控和告警**：监控事务执行情况，及时发现问题
5. **文档记录**：记录隔离级别的选择和原因
## 六、InnoDB如何解决幻读
### 6.1 MVCC机制
InnoDB通过**MVCC（Multi-Version Concurrency Control，多版本并发控制）**机制来解决并发问题：
- 每行数据都有多个版本
- 事务读取时，只能看到已提交的版本
- 通过undo log实现版本管理
### 6.2 Next-Key Lock
InnoDB通过**Next-Key Lock（临键锁）**来防止幻读：
- 锁定索引记录和索引记录之间的间隙
- 防止其他事务在范围内插入数据
- 结合MVCC，基本解决了幻读问题
### 6.3 示例
```sql
-- 事务A
BEGIN;
SELECT * FROM users WHERE age > 30; -- 返回3条记录
-- 事务B（在另一个会话）
BEGIN;
INSERT INTO users (name, age) VALUES ('新用户', 35); -- 会被阻塞
COMMIT;
-- 事务A
SELECT * FROM users WHERE age > 30; -- 仍然返回3条记录
COMMIT;
```
## 七、隔离级别选择指南
### 7.1 选择原则
1. **默认使用可重复读**：大多数场景使用默认隔离级别即可
2. **金融场景使用串行化**：对一致性要求极高的场景
3. **统计场景使用读已提交**：对一致性要求不高的查询场景
4. **避免使用读未提交**：除非对数据准确性要求极低
### 7.2 场景示例
| 业务场景 | 推荐隔离级别 | 原因 |
|---------|------------|------|
| 一般业务 | 可重复读（RR） | 平衡性能和安全性 |
| 金融支付 | 串行化 | 需要强一致性 |
| 统计报表 | 读已提交（RC） | 对一致性要求不高 |
| 日志记录 | 读已提交（RC） | 对一致性要求低 |
## 八、总结
MySQL事务隔离级别是数据库并发控制的核心概念：
1. **理解三种并发问题**：脏读、不可重复读、幻读
2. **掌握四种隔离级别**：读未提交、读已提交、可重复读、串行化
3. **了解默认隔离级别**：InnoDB默认是可重复读（RR）
4. **根据业务选择**：不同业务场景需要不同的隔离级别
5. **注意实际应用**：了解隔离级别，避免出现莫名其妙的问题
**核心思想：**
- 隔离级别是在性能和安全性之间的权衡
- 没有完美的隔离级别，只有合适的隔离级别
- 了解隔离级别，才能写出正确的并发程序
- InnoDB的默认隔离级别已经能解决90%以上的问题
通过深入理解事务隔离级别，我们可以更好地设计并发程序，避免数据不一致的问题。2、【Java面试】8年开发的粉丝想去挑战一下大厂，结果被拒，回来查了很多资料也没搞明白，Mysql为什么使用B+Tree作为索引结构？_哔哩哔哩_bilibili
# MySQL为什么使用B+树作为索引结构：深度解析
## 引言
一个工作了八年的粉丝，提出了一个问题。他说，这个问题是去阿里面试的时候被问到的。自己查了很多资料，也没有搞明白，希望我能够帮他去解答一下。
这个问题是：**MySQL里面为什么要使用B+树来作为索引结构？**
好的，关于这个问题呢，我们看看普通人和高手的回答。
## 一、普通人的回答
**普通人的回答：**
嗯，MySQL为什么使用B+树作为索引啊？嗯，就是我觉得有几个原因吧，就是，第一个是，就是B+树它的特征啊，就是说，它相对B树来说它的这个，这个，**非叶子节点**是不存数据的，它所有数据都存储在**叶子节点**，那么意味着，就是，嗯，那我每，我的这个索引，所以说，所有的索引就每一个层里面能够存储的这个索引的数量是会更多。
然后第二个就是说，因为它相对于B树来说，它的查询IO次数会更稳定，还是因为说所有的数据都存在叶子节点的原因，因为如果我要在B+树里面去做一次查询的时候，它还是最重要到叶子节点去获取数据，对吧？但是B树不一样，B树的话就是比如说我，我在第一层就查到这个数据，只要返回来，但是有可能我第一层查不到，我需要查到第二层第三层，所以它的IO次数不稳定的。所以相对于说，这种情况下，那么，它的这个对稳定性吧，主要是稳定性是这一块。对。
**问题分析：**
普通人的回答主要存在以下问题：
- 只提到了B+树相比B树的一些特点，但没有深入分析
- 没有说明为什么选择B树/B+树而不是二叉树
- 没有提到范围查询、全局扫描等优势
- 缺乏系统性的分析思路
## 二、高手的回答
### 2.1 为什么选择B树/B+树而不是二叉树？
**高手的回答：**
我会从几个方面来回答。
**首先，常规的数据库存储引擎，一般都是采用B树或者B+树来实现索引的存储。**
因为B树是一种**多路平衡树**。用这种存储结构来存储大量数据的情况下，它的整体高度相比**二叉树**来说会矮很多。
**而对于数据库来说，所有的数据必然是存储在磁盘上的。而磁盘IO的效率实际上是很低的。特别是在随机磁盘IO的一个情况下效率更低，所以树的高度就能够决定磁盘IO的次数。磁盘IO次数越少，那么对性能提升就会越大。这也是为什么采用B树作为索引存储结构的原因。**
**对比分析：**
假设我们有1000万条数据：
- **二叉树**：高度约为log₂(10,000,000) ≈ 24层，需要24次磁盘IO
- **B树（假设每个节点存储100个索引）**：高度约为log₁₀₀(10,000,000) ≈ 4层，需要4次磁盘IO
**结论：** B树/B+树的高度远低于二叉树，大大减少了磁盘IO次数。
### 2.2 B+树相比B树的优化
但是在MySQL的**InnoDB**存储引擎里面，它采用的是一种增强的B树结构，**B+树**来作为索引和数据的一个存储结构。
相比较于B树的结构啊，B+树做了几个方面的一个优化：
**首先第一个是，B+树的所有数据都存在叶子节点上，而非叶子节点只会存储索引。**
**第二个是，叶子节点里面的数据是使用双向链表的方式来进行关联的。**
### 2.3 B+树的优势分析
所以使用B+树来实现索引的一个存储结构，我认为有几个方面的一个原因：
#### 优势一：更高的存储密度，减少IO次数
**第一个，B+树的非叶子节点不会存储数据，所以每一层能够存储的索引数量会增加。**
那么意味着B+树在**层高相同**的情况下，它存储的数据量会比B树要更多。这样的话，**实际的IO次数会更少**。
**对比示例：**
假设每个节点大小为16KB，每个索引项8字节：
- **B树**：非叶子节点存储索引+数据，每个节点约存储1000个索引项
- **B+树**：非叶子节点只存储索引，每个节点约存储2000个索引项
**结果：** B+树的扇出（fan-out）更大，树的高度更低，IO次数更少。
#### 优势二：范围查询效率更高
**第二个，在MySQL里面呢，范围查询是一个比较常用的操作，而B+树的所有数据都是存在叶子节点里，并且使用了双向链表来关联。**
所以在查询的时候只需要查两个节点，然后进行**遍历**就好了。而B树需要获取所有的节点，所以B+树在范围查询上效率会更高一些。
**范围查询示例：**
```sql
-- 查询年龄在20到30之间的用户
SELECT * FROM users WHERE age BETWEEN 20 AND 30;
```
**B+树的查询过程：**
1. 定位到age=20的叶子节点
2. 通过双向链表顺序遍历到age=30的节点
3. 只需要访问连续的叶子节点，IO次数少
**B树的查询过程：**
1. 需要访问多个非叶子节点
2. 需要多次随机IO
3. IO次数多，效率低
#### 优势三：IO次数更稳定
**第三个，在数据的检索方面，由于所有的数据都是存在叶子节点，所以B+树的IO次数会更加稳定一些。**
**B树的IO次数：**
- 如果数据在根节点：1次IO
- 如果数据在第二层：2次IO
- 如果数据在叶子节点：3-4次IO
- **IO次数不稳定**
**B+树的IO次数：**
- 所有数据都在叶子节点
- 查询路径长度固定（树的高度）
- **IO次数稳定**，便于性能评估和优化
#### 优势四：全局扫描能力更强
**第四个，因为B+树的所有数据都是存在叶子节点，所以B+树的全局扫描能力是更强一些的，因为它只需要扫描叶子节点，但是B树需要去遍历整个树。**
**全表扫描示例：**
```sql
-- 全表扫描
SELECT * FROM users;
```
**B+树的全表扫描：**
- 只需要顺序遍历叶子节点的双向链表
- 顺序IO，效率高
- 适合大数据量的全表扫描
**B树的全表扫描：**
- 需要遍历整个树结构
- 随机IO多，效率低
#### 优势五：自增主键优化
**另外，B+树在一个结构，如果采用自增的整型数据作为主键，还能够更好地去避免增加数据的时候，带来的叶子节点分裂导致了大量运算的一个问题。**
**自增主键的优势：**
- 新数据总是插入到最后一个叶子节点
- 减少节点分裂的概率
- 提高插入性能
**非自增主键的问题：**
- 新数据可能插入到中间位置
- 容易导致节点分裂
- 影响插入性能
### 2.4 技术方案选择的思考
**总的来说，我认为技术方案的选择，更多的是去解决当前场景下的一些特定问题。并未必说B+树就是最好的选择。**
就像**MongoDB**里面采用**B树**结构。本质上来说其实是**关系型数据库**和非关系型数据库的一个差异。
**不同数据库的选择：**
| 数据库 | 索引结构 | 原因 |
|--------|---------|------|
| MySQL InnoDB | B+树 | 适合范围查询、全表扫描 |
| MongoDB | B树 | 文档数据库，查询模式不同 |
| PostgreSQL | B+树 | 类似MySQL，关系型数据库 |
| Oracle | B+树 | 关系型数据库 |
## 三、B+树结构详解
### 3.1 B+树的基本结构
```
[根节点]
/ | \
[非叶子] [非叶子] [非叶子]
/ | \ / | \ / | \
[叶子] [叶子] [叶子] [叶子] [叶子] [叶子]
↓ ↓ ↓ ↓ ↓ ↓
[数据] [数据] [数据] [数据] [数据] [数据]
↔ ↔ ↔ ↔ ↔ ↔
双向链表连接
```
**特点：**
- **非叶子节点**：只存储索引（键值），不存储数据
- **叶子节点**：存储索引和数据
- **双向链表**：叶子节点之间通过双向链表连接
### 3.2 InnoDB中的B+树
**聚簇索引（主键索引）：**
- 叶子节点存储完整的行数据
- 表数据本身就是按照主键索引组织的
**非聚簇索引（辅助索引）：**
- 叶子节点存储主键值
- 需要通过主键值回表查询完整数据
## 四、B+树 vs B树 vs 二叉树对比
### 4.1 结构对比
| 特性 | 二叉树 | B树 | B+树 |
|------|--------|-----|------|
| 节点存储 | 索引+数据 | 索引+数据 | 非叶子节点只存索引，叶子节点存数据 |
| 树高度 | 高（log₂N） | 中等（logₘN） | 中等（logₘN） |
| 范围查询 | 效率低 | 效率中等 | 效率高（双向链表） |
| 全表扫描 | 效率低 | 效率低 | 效率高（顺序遍历） |
| IO稳定性 | 不稳定 | 不稳定 | 稳定 |
### 4.2 性能对比
假设存储1000万条数据：
| 操作 | 二叉树 | B树 | B+树 |
|------|--------|-----|------|
| 单点查询IO次数 | 20-24次 | 3-4次 | 3-4次 |
| 范围查询IO次数 | 高 | 中等 | 低（顺序IO） |
| 全表扫描 | 随机IO多 | 随机IO多 | 顺序IO，效率高 |
| 插入性能 | 低 | 中等 | 高（自增主键） |
## 五、实际应用场景
### 5.1 MySQL InnoDB的选择
**为什么InnoDB选择B+树：**
1. **范围查询频繁**：SQL中经常使用BETWEEN、>、<等范围查询
2. **全表扫描需求**：统计、聚合等操作需要全表扫描
3. **顺序访问优化**：B+树的顺序访问性能好
4. **稳定性要求**：IO次数稳定，便于性能评估
### 5.2 MongoDB的选择
**为什么MongoDB选择B树：**
1. **查询模式不同**：文档数据库，查询模式更灵活
2. **数据局部性**：B树的数据和索引在一起，局部性好
3. **随机访问**：更适合随机访问场景
## 六、总结
MySQL使用B+树作为索引结构的原因：
1. **相比二叉树**：树高度低，IO次数少
2. **相比B树**：
- 非叶子节点不存数据，存储密度更高
- 范围查询效率更高（双向链表）
- IO次数更稳定
- 全表扫描能力更强
- 自增主键优化更好
**核心思想：**
- 技术方案的选择，更多的是去解决当前场景下的一些特定问题
- 并未必说B+树就是最好的选择，要看具体场景
- 关系型数据库适合B+树，文档数据库可能适合B树
**对于为什么要选择某某技术的这一类问题啊，其实很好回答。只要你对这个技术本身的特性足够了解，那么自然就知道为什么要这么设计了。**
就像我们在**业务开发**里面呢，知道什么时候使用List，什么时候使用Map，道理是一样的。
## 七、面试回答要点
### 7.1 回答框架
1. **为什么不用二叉树？** 树高度高，IO次数多
2. **为什么选择B树/B+树？** 多路平衡树，树高度低
3. **为什么B+树比B树好？** 五个方面的优势
4. **技术选型的思考**：根据场景选择，没有银弹
### 7.2 关键点
- **理解本质**：B+树是为了减少磁盘IO
- **理解优势**：范围查询、全表扫描、IO稳定性
- **理解场景**：不同数据库有不同的选择
- **理解权衡**：没有完美的方案，只有合适的方案
3、【Java面试】请说一下Mysql索引的优点和缺点，高手的回答堪称教科书!_哔哩哔哩_bilibili
# MySQL索引优缺点全面解析：面试必问知识点
## 引言
今天分享的这段面试题是让一个工作了四年的小伙子去大众点评拿了60万的年薪。这段面试题是：**请你说一下MySQL索引的优点和缺点。**
关于这个问题的高手部分的回答呢，我已经整理成了文档。如果你想获得的话可以在我的主页上进入我的粉丝群。
关于这个题，我们来看看普通人和高手的回答。
## 一、普通人的回答
**普通人的回答：**
呃，MySQL索引的优点。优点的话就是我们**加索引之后**可以去提高数据的一个**检索效率**。呃，就很显然就是你**加索引没加索引**的时候，他的一个**查询效率**是不一样的。
然后缺点的话就是说，嗯，**索引**。如果索引的数量太多，他会在做索引的维护的时候，如果的数量很大，他会占用很长的时间。然后还有就是不能在一些像性别类的一些**字段**上建立索引。
**问题分析：**
普通人的回答主要存在以下问题：
- 只提到了索引提高查询效率，但没有深入分析原因
- 只提到了索引维护的开销，但没有系统性的分析
- 只提到了性别字段不适合建索引，但没有说明原因
- 缺乏对索引本质的理解
- 没有提到索引的其他优点和缺点
## 二、高手的回答
### 2.1 索引的本质
**高手的回答：**
好的。**索引是一种能够去帮助MySQL高效的去从磁盘去检索数据的一种数据结构。**
在MySQL的**InnoDB**引擎里面采用的是**B+树**的结构来去实现索引和数据的存储。
### 2.2 索引的优点
在我看来，MySQL里面的索引的优点能有很多，我简单罗列几点：
#### 优点一：减少磁盘IO次数，提升查询性能
**第一个点，通过B+树的结构来存储数据，可以去大大减少数据检索时候的一个磁盘IO次数，从而去提升数据的查询性能。**
**原理分析：**
- **没有索引**：需要全表扫描，逐行比较，IO次数 = 数据行数
- **有索引**：通过B+树快速定位，IO次数 = 树的高度（通常3-4次）
**示例：**
假设有1000万条数据：
```sql
-- 没有索引：需要扫描1000万行
SELECT * FROM users WHERE id = 5000000; -- 可能需要1000万次IO
-- 有索引：只需要3-4次IO
SELECT * FROM users WHERE id = 5000000; -- 只需要3-4次IO
```
**性能提升：** 从O(n)降低到O(log n)，性能提升巨大。
#### 优点二：范围查询效率高
**第二个，B+树索引在进行范围查找的时候只需要去找到起始节点，然后基于叶子节点里面的链表结构往下读取就行了。查询效率会比较高。**
**范围查询示例：**
```sql
-- 查询年龄在20到30之间的用户
SELECT * FROM users WHERE age BETWEEN 20 AND 30;
```
**B+树的查询过程：**
1. 通过B+树定位到age=20的起始叶子节点（3-4次IO）
2. 通过叶子节点的双向链表顺序读取到age=30的节点（顺序IO）
3. 只需要访问连续的叶子节点，IO次数少，效率高
**优势：**
- 顺序IO，性能好
- 不需要多次随机IO
- 适合大数据量的范围查询
#### 优点三：保证数据唯一性
**第三个，通过唯一索引的约束可以去保证数据表里面的每一行数据的一个唯一性。**
**唯一索引示例：**
```sql
-- 创建唯一索引
CREATE UNIQUE INDEX idx_email ON users(email);
-- 插入重复数据会失败
INSERT INTO users(email) VALUES ('test@example.com');
INSERT INTO users(email) VALUES ('test@example.com'); -- 失败，违反唯一约束
```
**优势：**
- 数据库层面保证数据唯一性
- 避免应用层重复检查
- 提高数据质量
#### 优点四：加速表连接
**索引可以加速表之间的连接操作。**
```sql
-- 连接查询
SELECT u.name, o.order_id
FROM users u
JOIN orders o ON u.id = o.user_id;
```
如果`orders.user_id`有索引，连接操作会更快。
#### 优点五：加速排序和分组
**索引可以帮助优化ORDER BY和GROUP BY操作。**
```sql
-- 如果age字段有索引，排序会更快
SELECT * FROM users ORDER BY age;
-- 如果status字段有索引，分组会更快
SELECT status, COUNT(*) FROM users GROUP BY status;
```
### 2.3 索引的缺点
当然，索引的不合理使用也会带来很多的一些缺点。
#### 缺点一：维护成本高
**第一个，数据在做增加、修改、删除操作的时候需要涉及到索引的一个维护，当数据量比较大的情况下，索引的维护会带来比较大的一个性能开销。**
**维护成本分析：**
**插入操作：**
- 需要更新B+树索引
- 可能需要节点分裂
- 影响插入性能
**更新操作：**
- 如果更新了索引字段，需要更新索引
- 可能需要节点重新组织
- 影响更新性能
**删除操作：**
- 需要从索引中删除记录
- 可能需要节点合并
- 影响删除性能
**示例：**
```sql
-- 插入100万条数据
-- 没有索引：可能只需要10分钟
-- 有索引：可能需要30分钟（索引维护开销）
INSERT INTO users (name, email) VALUES ...;
```
#### 缺点二：索引数量限制
**第二个，一个表里面是允许存在一个聚簇索引和多个非聚簇索引的，但是索引的数量不能创建太多，否则会造成索引的维护成本过高。**
**问题分析：**
- **存储空间**：每个索引都需要额外的存储空间
- **维护成本**：每次数据变更都需要更新所有索引
- **写入性能**：索引越多，写入性能越差
**建议：**
- 一般建议一个表的索引数量不超过5-10个
- 根据实际查询需求创建索引
- 定期审查和删除不使用的索引
#### 缺点三：索引字段选择限制
**第三个，创建索引的时候我们需要去考虑索引字段值的一个分散性，如果字段一个重复数据比较多，索引的效果会大打折扣。**
**问题分析：**
**低选择性字段不适合建索引：**
```sql
-- 性别字段：只有'男'、'女'两个值
-- 选择性 = 2 / 1000000 = 0.000002（极低）
-- 索引效果很差
CREATE INDEX idx_gender ON users(gender); -- 不推荐
-- 用户ID：每个值都不同
-- 选择性 = 1000000 / 1000000 = 1（极高）
-- 索引效果很好
CREATE INDEX idx_user_id ON users(user_id); -- 推荐
```
**选择性计算公式：**
```
选择性 = 不同值的数量 / 总记录数
```
- **选择性 > 0.1**：适合建索引
- **选择性 < 0.1**：不适合建索引
**不适合建索引的字段：**
- 性别（男/女）
- 状态（启用/禁用）
- 布尔类型字段
- 重复度高的字段
#### 缺点四：占用存储空间
**索引需要额外的存储空间。**
- **聚簇索引**：数据和索引存储在一起，空间占用相对较小
- **非聚簇索引**：需要额外的存储空间
- **复合索引**：字段越多，占用空间越大
**示例：**
假设有1000万条数据，每条数据1KB：
- **数据本身**：1000万 × 1KB = 10GB
- **主键索引**：约500MB
- **5个辅助索引**：约2.5GB
- **总存储空间**：约13GB（索引占用约23%）
#### 缺点五：索引失效问题
**不合理的查询会导致索引失效。**
**索引失效的场景：**
```sql
-- 1. 在索引列上使用函数
SELECT * FROM users WHERE YEAR(create_time) = 2023; -- 索引失效
-- 2. 在索引列上使用运算符
SELECT * FROM users WHERE age + 1 > 30; -- 索引失效
-- 3. LIKE查询以%开头
SELECT * FROM users WHERE name LIKE '%张%'; -- 索引失效
-- 4. 不满足最左前缀原则
-- 假设有联合索引(name, age, city)
SELECT * FROM users WHERE age = 30; -- 索引失效
```
## 三、索引使用的最佳实践
### 3.1 何时创建索引
**适合创建索引的场景：**
1. **经常用于WHERE条件的字段**
2. **经常用于JOIN的字段**
3. **经常用于ORDER BY的字段**
4. **选择性高的字段**
5. **外键字段**
### 3.2 何时不创建索引
**不适合创建索引的场景：**
1. **选择性低的字段**（如性别、状态）
2. **很少用于查询的字段**
3. **经常更新的字段**（维护成本高）
4. **数据量很小的表**（全表扫描更快）
5. **频繁插入、删除的表**（维护成本高）
### 3.3 索引设计原则
1. **最左前缀原则**：联合索引要遵循最左前缀
2. **覆盖索引**：尽量使用覆盖索引，减少回表
3. **索引数量控制**：一个表不要超过5-10个索引
4. **定期审查**：删除不使用的索引
5. **监控索引使用**：使用`SHOW INDEX`和`EXPLAIN`分析
## 四、技术方案选择的思考
**在我看来，任何技术方案都会有两面性。大部分情况下，技术方案的选择更多的是看重它的优势，和当前这个问题的匹配度。**
### 4.1 权衡原则
**索引的使用需要权衡：**
- **查询性能 vs 写入性能**：索引提高查询性能，但降低写入性能
- **存储空间 vs 查询效率**：索引占用空间，但提高查询效率
- **维护成本 vs 查询收益**：索引需要维护，但查询更快
### 4.2 选择建议
1. **读多写少的场景**：适合创建更多索引
2. **写多读少的场景**：谨慎创建索引
3. **OLTP系统**：索引要精而准
4. **OLAP系统**：可以创建更多索引
## 五、总结
MySQL索引的优点和缺点：
### 5.1 优点
1. **减少磁盘IO次数**：通过B+树结构，大幅减少IO次数
2. **范围查询效率高**：利用双向链表，顺序IO效率高
3. **保证数据唯一性**：唯一索引约束
4. **加速表连接**：提高JOIN性能
5. **加速排序和分组**：优化ORDER BY和GROUP BY
### 5.2 缺点
1. **维护成本高**：增删改操作需要维护索引
2. **索引数量限制**：不能创建太多索引
3. **字段选择限制**：低选择性字段不适合建索引
4. **占用存储空间**：索引需要额外存储空间
5. **索引失效问题**：不合理的查询会导致索引失效
### 5.3 核心思想
- **技术方案都有两面性**：没有完美的方案
- **根据场景选择**：看重优势与问题的匹配度
- **权衡利弊**：在查询性能和写入性能之间权衡
- **持续优化**：定期审查和优化索引
**行业竞争加剧，再加上现在整个大环境不是特别好。各个一二线大厂都在裁员。带来的问题是，人才的筛选难度同步增加，找工作会越来越困难。**
这题目考察的是求职者对于MySQL的理解程度，其实不算难，但在我看来，卡住了很多人。
通过系统性地理解索引的优缺点，我们可以在实际开发中更好地使用索引，提升系统性能。