110 lines
8.2 KiB
Markdown
110 lines
8.2 KiB
Markdown
## ACID vs BASE
|
||
|
||
**ACID**（原子性、一致性、隔离性、持久性）和 **BASE**（基本可用、软状态、最终一致性）是数据库事务和系统设计的两种核心理念，分别适用于不同场景。
|
||
|
||
### **ACID**
|
||
*适用于传统关系型数据库（如 MySQL、PostgreSQL）*
|
||
1. **原子性（Atomicity）**：事务要么全部成功，要么全部失败回滚。
|
||
2. **一致性（Consistency）**：数据始终符合预定义规则（如约束、触发器）。
|
||
3. **隔离性（Isolation）**：并发事务互不干扰，结果等同于串行执行。
|
||
4. **持久性（Durability）**：事务提交后数据永久保存，即使系统崩溃也不丢失。
|
||
|
||
**典型场景**：银行转账、订单支付、库存扣减等对数据准确性要求极高的场景。
|
||
|
||
### **BASE**
|
||
*适用于分布式 NoSQL 系统（如 Cassandra、MongoDB）*
|
||
1. **基本可用（Basically Available）**：系统即使部分故障，仍能响应请求（允许降级）。
|
||
2. **软状态（Soft State）**：数据可能随时间变化，无需实时同步。
|
||
3. **最终一致性（Eventually Consistent）**：数据更新会延迟同步，但最终全局一致。
|
||
|
||
**典型场景**：社交网络动态、电商商品浏览、日志存储等高并发、可容忍短暂不一致的场景。
|
||
|
||
|
||
### **核心差异**
|
||
| **维度** | **ACID** | **BASE** |
|
||
|----------------|-----------------------------------|-----------------------------------|
|
||
| **一致性** | 强一致性（实时） | 最终一致性（延迟） |
|
||
| **优先目标** | 数据安全与准确性 | 高可用性与扩展性 |
|
||
| **适用系统** | 单机/集中式数据库 | 分布式系统（如微服务、云原生） |
|
||
| **性能特点** | 读写延迟较高，吞吐量较低 | 读写延迟低，吞吐量高 |
|
||
|
||
**一句话总结**：
|
||
- **ACID**：牺牲性能换安全，适合“钱不能错”（如银行系统）。
|
||
- **BASE**：牺牲强一致换高可用，适合“用户能等”（如微博评论）。
|
||
|
||
根据业务需求选择：**要么严格保数据，要么灵活保体验**。
|
||
|
||
## 索引的分类
|
||
- 按 **「数据结构」** 分类：B+tree索引、Hash索引、Full-text索引。
|
||
- 按 **「物理存储」** 分类：聚簇索引（主键索引）、二级索引（辅助索引）。
|
||
- 按 **「字段特性」** 分类：主键索引、唯一索引、普通索引、前缀索引。
|
||
- 按 **「字段个数」** 分类：单列索引、联合索引。
|
||
|
||
|
||
## InnoDB默认索引
|
||
在创建表时，InnoDB 存储引擎会根据不同的场景选择不同的列作为索引：
|
||
|
||
- 如果有主键，默认会使用主键作为聚簇索引的索引键（key）；
|
||
- 如果没有主键，就选择第一个不包含 NULL 值的唯一列作为聚簇索引的索引键（key）；
|
||
- 在上面两个都没有的情况下，InnoDB 将自动生成一个**隐式自增 id (不可见的名为row_id的列名为GEN_CLUST_INDEX的聚簇索引，该列是一个6字节的自增数值)** 列作为聚簇索引的索引键（key）；
|
||
其它索引都属于**辅助索引（Secondary Index）**，也被称为**二级索引或非聚簇索引**。创建的主键索引和二级索引默认使用的是 **B+Tree 索引**。
|
||
|
||
## MySQL 的存储引擎有哪些？为什么常用InnoDB？
|
||
MySQL 的存储引擎常用的主要有 3 个：
|
||
|
||
- **InnoDB存储引擎**：支持事务处理，支持外键，支持崩溃修复能力和并发控制。如果需要对事务的完整性要求比较高（比如银行），要求实现并发控制（比如售票），那选择InnoDB有很大的优势。如果需要频繁的更新、删除操作的数据库，也可以选择InnoDB，因为支持事务的提交（commit）和回滚（rollback）。
|
||
- **MyISAM存储引擎**：插入数据快，空间和内存使用比较低。如果表主要是用于插入新记录和读出记录，那么选择MyISAM能实现处理高效率。如果应用的完整性、并发性要求比 较低，也可以使用。如果数据表主要用来插入和查询记录，则MyISAM引擎能提供较高的处理效率
|
||
- **MEMORY存储引擎**：所有的数据都在内存中，数据的处理速度快，但是安全性不高。如果需要很快的读写速度，对数据的安全性要求较低，可以选择MEMOEY。它对表的大小有要求，不能建立太大的表。所以，这类数据库只使用在相对较小的数据库表。如果只是临时存放数据，数据量不大，并且不需要较高的数据安全性，可以选择将数据保存在内存中的Memory引擎，MySQL中使用该引擎作为临时表，存放查询的中间结果
|
||
**常用InnoDB的原因是支持事务，且最小锁的粒度是行级锁。**
|
||
|
||
## 执行一条 SQL 查询语句，期间发生了什么？
|
||
|
||
- 连接器：建立连接，管理连接、校验用户身份；
|
||
- 查询缓存：查询语句如果命中查询缓存则直接返回，否则继续往下执行。MySQL 8.0 已删除该模块；
|
||
- 解析 SQL，通过解析器对 SQL 查询语句进行词法分析、语法分析，然后构建语法树，方便后续模块读取表名、字段、语句类型；
|
||
- 执行 SQL：执行 SQL 共有三个阶段：
|
||
- 预处理阶段：检查表或字段是否存在；将 select * 中的 * 符号扩展为表上的所有列。
|
||
- 优化阶段：基于查询成本的考虑， 选择查询成本最小的执行计划；
|
||
- 执行阶段：根据执行计划执行 SQL 查询语句，从存储引擎读取记录，返回给客户端；
|
||
|
||
|
||
|
||
## MySQL 的 NULL 值是怎么存放的？
|
||
|
||
MySQL 的 Compact 行格式中会用「NULL值列表」来标记值为 NULL 的列，NULL 值并不会存储在行格式中的真实数据部分。
|
||
|
||
NULL值列表会占用 1 字节空间，当表中所有字段都定义成 NOT NULL，行格式中就不会有 NULL值列表，这样可节省 1 字节的空间。
|
||
|
||
MySQL 怎么知道 varchar(n) 实际占用数据的大小？
|
||
|
||
MySQL 的 Compact 行格式中会用「变长字段长度列表」存储变长字段实际占用的数据大小。
|
||
|
||
## varchar(n) 中 n 最大取值为多少？
|
||
|
||
一行记录最大能存储 65535 字节的数据，但是这个是包含「变长字段字节数列表所占用的字节数」和「NULL值列表所占用的字节数」。所以， 我们在算 varchar(n) 中 n 最大值时，需要减去这两个列表所占用的字节数。
|
||
|
||
如果一张表只有一个 varchar(n) 字段，且允许为 NULL，字符集为 ascii。varchar(n) 中 n 最大取值为 65532。
|
||
|
||
计算公式：65535 - 变长字段字节数列表所占用的字节数 - NULL值列表所占用的字节数 = 65535 - 2 - 1 = 65532。
|
||
|
||
如果有多个字段的话，要保证所有字段的长度 + 变长字段字节数列表所占用的字节数 + NULL值列表所占用的字节数 <= 65535。
|
||
|
||
## 行溢出后，MySQL 是怎么处理的？
|
||
|
||
如果一个数据页存不了一条记录，InnoDB 存储引擎会自动将溢出的数据存放到「溢出页」中。
|
||
|
||
Compact 行格式针对行溢出的处理是这样的：当发生行溢出时，在记录的真实数据处只会保存该列的一部分数据，而把剩余的数据放在「溢出页」中，然后真实数据处用 20 字节存储指向溢出页的地址，从而可以找到剩余数据所在的页。
|
||
|
||
Compressed 和 Dynamic 这两种格式采用完全的行溢出方式，记录的真实数据处不会存储该列的一部分数据，只存储 20 个字节的指针来指向溢出页。而实际的数据都存储在溢出页中。
|
||
|
||
## B+索引
|
||
|
||
|
||
|
||
相比于标准的B+树，InnoDB使用的B+树有如下特点：
|
||
|
||
- B+ 树的叶子节点之间是用「双向链表」进行连接，既能向右遍历、也能向左遍历
|
||
- B+ 树点节点内容是数据页，数据页里存放了用户的记录以及各种信息，每个数据页默认大小是 16 KB
|
||
|
||
|