DBA【八股文】01：数据库相关术语介绍

一、关系型数据库和非关系型数据库区别？

1、什么是关系型数据库【 ​​RDBMS】？

关系型数据库（Relational Database Management System, ​​RDBMS​​）是一种基于​​关系模型​​的数据库管理系统，其核心思想是将数据组织成​​二维表格（表）​​，并通过严格的数学关系（如集合、元组、属性）定义数据之间的关联。

它是目前最主流的数据库类型之一，广泛应用于需要强一致性、事务支持和复杂查询的场景。

（1）开源关系型数据库

重点：MySQL、PG

（2）商业关系型数据库​

重点：Oracle

（3）国产数据库

2、什么是非关系型数据库【NoSQL】？

NoSQL（Not Only SQL）是一类​​非关系型数据库​​的统称，其设计理念与传统的​​关系型数据库（RDBMS）​​不同，更强调​​灵活的模式、高扩展性、分布式存储​​，适合处理海量数据、高并发或非结构化数据场景。

（1）键值（Key-Value）数据库​

数据以“键（Key）-值（Value）”对形式存储，Key 是唯一标识，Value 可以是任意类型（字符串、对象、二进制等）。读写操作直接基于 Key，简单高效，适合快速查找。

（a）Redis【重点】

• 特点：内存存储（支持持久化）、支持丰富的数据结构（字符串、哈希、列表、集合、有序集合等）、单线程（避免锁竞争）、支持发布订阅、Lua 脚本。
• 适用场景： 缓存（减少数据库压力）、会话存储（如 Web 应用用户登录状态）、计数器（点赞数、秒杀库存）、实时排行榜（有序集合）。

（b）Memcached

• 特点：纯内存键值存储、简单高效（仅支持字符串类型）、分布式集群（通过客户端分片）、无持久化（重启数据丢失）。
• 适用场景：简单的缓存场景（如静态资源缓存），但对复杂操作支持有限，逐渐被 Redis 替代。

（c）Riak

• 特点：分布式键值存储（高容错）、支持多数据中心复制、提供 HTTP API、支持轻量级 MapReduce。
• 适用场景： 需要高可用和分布式的场景（如日志存储、用户偏好数据）。

（2）文档（Document）数据库

数据以“文档”形式存储（通常是半结构化的 JSON、BSON 或 XML 格式），文档内部可嵌套其他文档或数组，Schema 灵活（同一集合的文档无需结构一致）。

（a）MongoDB

• 特点：最流行的文档数据库、支持 BSON（二进制
  JSON）格式、自动分片（水平扩展）、支持索引（单键/复合/地理空间等）、内置聚合框架（类似 SQL 的 GROUP BY）。
• 适用场景：内容管理系统（如博客文章）、用户行为数据（嵌套的日志字段）、实时分析（结合聚合管道）、需要灵活模式的场景（如电商商品属性动态扩展）。

（b）CouchDB

• 特点：基于 Erlang 开发、支持多主复制（冲突解决）、提供 RESTful API、数据以 JSON
  存储、支持离线同步（移动端友好）。
• 适用场景：需要离线优先的应用（如移动端笔记应用）、需要数据同步的场景（如协同编辑）。

（3）列族（Column-Family）数据库

数据按“行键（RowKey）”组织，每一行包含多个“列族（Column Family）”，每个列族下可动态添加列（列名不固定）。数据按列族集中存储，适合批量读写。

（a）HBase

• 特点：基于 HDFS 存储、依赖 ZooKeeper 协调、支持 Region 分片（自动扩展）、强一致性（基于
  RowKey）、适合随机读写。
• 适用场景：实时数据存储（如 IoT 传感器数据）、高频读写场景（如社交动态流）、作为大数据平台的实时数据入口（衔接
  Hive/Spark）。

（b）​​Apache Cassandra​​

• 特点：去中心化（无单点）、支持多数据中心复制、高写入吞吐量（每秒百万级）、线性扩展（添加节点即提升性能）、基于时间戳的版本控制（解决写入冲突）。
• 适用场景：需要高写入和高可用的场景（如广告点击日志、电商订单流水）、全球分布的应用（如跨国公司的用户行为数据）

（4）图（Graph）数据库​

数据以“节点（Node）”和“边（Edge）”的形式存储，节点表示实体（如用户、商品），边表示实体间的关系（如“关注”“购买”）。支持高效的图遍历（如查找“朋友的朋友”）。

（a）Neo4j

• 特点：最成熟的图数据库、支持 Cypher 查询语言（声明式图查询）、ACID 事务、可视化工具（Neo4j Browser）。
• 适用场景：社交网络（好友推荐）、知识图谱（实体关系查询）、欺诈检测（资金转移链路追踪）、推荐系统（用户-商品关联）。

（b）Amazon Neptune

• 特点：AWS 托管的图数据库、支持 Gremlin（Apache TinkerPop 标准）和
  SPARQL（语义网查询）两种查询语言、高可用（多可用区部署）。
• 适用场景：云原生应用（如 AWS 上的知识图谱、社交关系分析）。

​​（5）其他类型 NoSQL​

部分数据库可能融合多种模型或针对特定场景优化：

​​宽列（Wide-Column）数据库​​： 本质属于列族变种，强调按列查询（如按时间范围扫描列）。代表：​​ClickHouse​​（虽主打 OLAP，但存储结构为宽列）。

​​多模型数据库​​： 支持多种数据模型（如键值+文档+图）。代表：​​OrientDB​​、​​ArangoDB​​（支持文档、图、键值）。

​​时序（Time-Series）数据库​​： 专为时间序列数据优化（如传感器指标、监控数据）。代表：​​InfluxDB​​、​​TimescaleDB​​（基于 PostgreSQL 的扩展）。

二、什么是事务？

1、定义

事务（Transaction）​​ 是数据库中​​一组不可分割的操作集合​​，其核心目标是确保数据的一致性和完整性。

它通过“原子性（Atomicity）”保证这组操作要么​​全部成功执行​​，要么​​全部失败回滚​​，避免因部分操作成功导致数据处于不一致的状态。

2、事务的生命周期​

一个完整的事务通常包含以下阶段：

​​开始（Begin）​​： 显式或隐式启动一个事务（如 SQL 中的 BEGIN TRANSACTION 或 START TRANSACTION）。
​​执行（Execute）​​： 执行事务内的操作（如增删改查）。
​​提交（Commit）​​： 若所有操作成功，提交事务，将修改永久写入数据库（如 SQL 中的 COMMIT）。
​​回滚（Rollback）​​： 若任意操作失败或主动终止，回滚事务，撤销所有已执行的操作（如 SQL 中的 ROLLBACK）。

三、什么是ACID?

ACID 是关系型数据库（RDBMS）中​​事务（Transaction）​​的核心特性，用于保证数据的可靠性和完整性。

它由四个关键属性的首字母组成：​​原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、**持久性（Durability）**​​。

这四个特性共同确保了数据库在面对各种异常（如系统崩溃、网络中断）时，仍能保持数据的一致性和正确性。

1、原子性（Atomicity）：事务的“全或无”​

（1）定义

事务是一个不可分割的操作单元，要么​​全部成功执行​​，要么​​全部失败回滚​​。若事务执行过程中发生错误（如硬件故障、约束冲突），数据库会撤销已执行的所有操作，使数据恢复到事务开始前的状态。

（2）举例

2、一致性（Consistency）：状态的“合法转换”​

（1）定义

事务执行前后，数据库从一个​​合法状态​​转换到另一个​​合法状态​​。这里的“合法状态”指数据必须满足所有预定义的约束（如主键唯一、外键关联、数值范围等）和业务规则（如账户余额不能为负）。

（2）举例

3、隔离性（Isolation）：事务的“互不干扰”​

（1）定义

多个并发执行的事务之间彼此隔离，一个事务的执行不会影响其他事务的结果。每个事务仿佛在“独立环境”中运行，最终结果与串行执行（逐个执行）的结果一致。

（2）举例

（3）隔离级别

实际中，完全隔离（串行执行）会严重影响性能，因此数据库允许设置不同的隔离级别（从低到高）：

​​读未提交（Read Uncommitted，RU）​​： 允许读取其他事务未提交的修改（可能读到“脏数据”）。

​​读已提交（Read Committed，RC）​​： 仅允许读取其他事务已提交的修改（默认级别，如 Oracle）。

​​可重复读（Repeatable Read，RR）​​：同一事务内多次读取同一数据结果一致（防止“不可重复读”）。这个是MySQL默认的隔离级别。

​​串行化（Serializable）​​： 事务完全串行执行（无并发，隔离性最高，性能最低）。

4、持久性（Durability）：数据的“永久保存”​

（1）定义

一旦事务成功提交（Commit），其对数据库的修改将​​永久保存​​，即使后续发生系统崩溃、磁盘故障等异常，数据也不会丢失。

（2）实现机制

数据库通常通过​​预写日志（Write-Ahead Logging, WAL）​​保证持久性：

事务执行时，先将所有修改操作记录到日志文件（如 MySQL 的 redo log、PostgreSQL 的 WAL）；

待事务提交时，先确保日志已持久化到磁盘；

最后再将日志中的修改应用到数据库数据文件。

若系统崩溃，重启后数据库可通过日志恢复已提交但未写入数据文件的修改。

四、什么是脏读、幻读、不可重复读？

脏读、不可重复读、幻读是数据库并发事务中常见的​​数据不一致问题​​，它们的本质是多个事务同时操作同一数据时，因事务隔离性不足导致的异常现象。

1、脏读（Dirty Read）​

（1）定义

一个事务（T1）读取到了另一个未提交事务（T2）修改的数据。若后续 T2 回滚，T1 读取的“修改”会被撤销，导致 T1 基于“脏数据”执行错误操作。

（2）关键特征

读取的是​​未提交​​的事务修改；
最终因 T2 回滚，T1 的读取结果无效。

（3）举例

（4）如何解决脏读？

通过设置隔离级别为​​读已提交（Read Committed, RC）​​可避免脏读。RC 要求事务只能读取其他事务​​已提交​​的修改，未提交的修改对其他事务不可见。

2、不可重复读

（1）定义

在同一事务（T1）内，多次读取同一数据，因其他已提交事务（T2）修改了该数据，导致两次读取结果不一致。

（2）关键特征

读取的是​​已提交​​的事务修改；
同一事务内多次读取同一数据，结果不同。

（3）示例

（4）如何解决不可重复读？

通过设置隔离级别为​​可重复读（Repeatable Read, RR）​​可避免不可重复读。RR 要求同一事务内多次读取同一数据时，结果与第一次读取一致（通过锁定或版本控制实现）。

3、幻读

（1）定义

在同一事务（T1）内，多次执行相同的查询语句，因其他已提交事务（T2）插入或删除了符合条件的行，导致每次查询的结果集行数不同（“幻觉”般新增或消失的行）。

（2）关键特征

读取的是​​已提交​​的事务修改；
同一查询语句的结果集行数变化（新增或删除符合条件的行）。

（3）示例

（4）如何解决幻读？

通过设置隔离级别为​​串行化（Serializable）​​可避免幻读。

串行化要求事务完全串行执行（无并发），但性能开销大。

实际中，部分数据库（如 MySQL）通过​​间隙锁（Gap Lock）​​或​​临键锁（Next-Key Lock）​​在可重复读级别解决幻读问题。

五、什么是锁？

1、定义

锁（Lock）​​ 是数据库系统中用于控制​​并发访问共享资源​​的核心机制，其本质是通过“加锁-解锁”的规则，确保多个事务在同时操作同一数据时，数据的一致性和完整性不被破坏。

它是解决数据库并发问题（如脏读、不可重复读、幻读）的关键手段，也是实现事务隔离性的重要工具。

2、锁的作用

在多事务并发执行的环境中，若多个事务同时修改同一数据，可能导致数据不一致（如脏读、不可重复读）。锁通过以下方式解决这些问题：

​​互斥访问​​： 同一时间仅允许一个事务访问被锁定的资源（如数据行），其他事务需等待锁释放后才能操作。
​​状态标记​​： 通过锁的类型（如共享锁、排他锁）标记资源的当前状态，告知其他事务是否可以安全访问。

3、分类

（1）按锁的粒度（锁定范围）划分

锁的粒度决定了锁定资源的精细程度，粒度越细（如行锁），并发性能越高，但管理成本也越高；粒度越粗（如表锁），并发性能越低，但实现简单。

（2）按锁的模式（操作权限）划分​

锁的模式定义了事务对资源的操作权限，常见的模式包括共享锁、排他锁，以及两者的衍生模式。

（3） 按锁的状态（附加功能）划分​

部分数据库会通过“意向锁”或“自增锁”等扩展锁模式，优化锁的管理效率。

4、锁的工作流程

锁的生命周期通常包括以下步骤：

​​加锁（Lock Acquisition）​​： 事务开始操作资源时，向数据库申请锁（如读取行时申请 S锁，修改行时申请 X锁）。

​​锁等待（Lock Waiting）​​： 若资源已被其他事务加锁且模式冲突（如当前事务申请 X锁，但资源已被 S锁持有），事务进入等待状态。

​​锁释放（Lock Release）​​： 事务提交（COMMIT）或回滚（ROLLBACK）后，释放所有持有的锁，唤醒等待的事务。

5、锁和事务隔离级别的关系

数据库的隔离级别（如读已提交、可重复读）本质上是通过调整锁的粒度和模式实现的。例如：

​​读已提交（RC）​​： 默认使用行级 S锁，读取后立即释放锁，允许其他事务修改同一行（可能产生不可重复读）。

​​可重复读（RR）​​： 使用行级 S锁并长期持有（直到事务结束），或在 MySQL 中通过 MVCC（多版本并发控制）避免加锁，确保同一事务内多次读取结果一致。

​​串行化（Serializable）​​： 强制使用表级 X锁或行级 X锁，所有事务串行执行（无并发，隔离性最高）。

6、典型数据库的锁实现​

不同数据库对锁的实现细节不同，例如：

​​MySQL（InnoDB）​​： 支持行锁（通过索引实现）、表锁（自动升级为行锁）、间隙锁（解决幻读）。
​​PostgreSQL​​： 支持行锁（FOR UPDATE/FOR SHARE）、表锁（ACCESS EXCLUSIVE）、多版本并发控制（MVCC，减少锁使用）。
​​Oracle​​： 默认使用行级多版本读（MVCC），仅在需要时加锁（如写操作），并发性能极高。

六、什么是索引？

1、定义

索引（Index）​​ 是数据库中为加速数据检索而设计的​​辅助数据结构​​，其核心作用类似于书籍的“目录”——通过预先存储数据的键值和对应位置的映射关系，避免全表扫描，大幅减少查询时的 I/O 操作和计算量。它是数据库性能优化的核心技术之一。

2、索引的特点

3、索引的分类

索引的分类方式多样，常见的分类维度包括​​数据结构​​、​​逻辑功能​​和​​存储方式​​。以下是最常用的分类：

（1）按数据结构划分（最核心的分类）​

索引的底层数据结构决定了其适用场景和性能特点，主流数据库（如 MySQL、PostgreSQL）主要使用以下结构：

（2）按逻辑功能划分​

根据索引的约束和用途，可分为以下类型：

4、索引的工作原理（以 B+ 树为例）​

B+ 树是关系型数据库中最常用的索引结构，其核心设计是为了高效处理磁盘 I/O。以下是其工作流程的简化说明：

（1）​​B+ 树结构​​：

• B+ 树是一种平衡多路搜索树，所有数据都存储在叶子节点（称为“数据页”），非叶子节点仅存储索引键值和子节点指针。
• 叶子节点通过双向链表连接，支持范围查询时的顺序遍历（如 WHERE age BETWEEN 20 AND 30）。

（2）​​查询过程​​：

• 当执行 SELECT * FROM user WHERE id=100 时，数据库首先从 B+ 树的根节点开始，根据 id=100
  向下查找，直到到达叶子节点，获取对应的数据行地址（如磁盘中的物理地址）。
• 最后通过地址读取数据行（若为覆盖索引，则直接从索引获取数据，无需额外读取数据行）。

（3）​​插入/更新过程​​：

• 当插入新数据时，数据库会更新 B+ 树结构，找到合适的位置插入新索引项，并调整树的高度以保持平衡（避免树过深导致查询变慢）。

七、什么是MVCC【多版本并发控制】？

多版本并发控制（Multi-Version Concurrency Control, MVCC） 是数据库中实现高并发事务处理的核心技术之一，主要用于解决读-写冲突问题。

它通过为数据维护多个历史版本，使得读操作可以访问旧版本数据，而写操作修改新版本，从而实现“读不阻塞写，写不阻塞读”的并发效果。

以下从核心思想、实现机制、可见性规则、典型应用及优缺点等方面展开说明。

1、MVCC 的核心思想

传统数据库通过锁机制解决并发冲突（如读锁阻塞写锁，写锁阻塞读锁），但会导致性能瓶颈（尤其在高并发读多写少场景）。MVCC 则通过“时间旅行”思维，让每个事务看到符合其隔离级别的数据版本，避免直接阻塞。

简单来说：

当事务要修改数据时，先复制一份旧版本到 “版本链” ，再修改新版本；

读操作根据自身事务的“时间戳”或“版本号”，从版本链中找到可见的旧版本，无需等待写锁释放。

2、MVCC 的关键实现机制

MVCC 的落地依赖以下核心组件和技术：

（1）数据版本存储：版本链（Version Chain）

每条数据行（Record）会维护一个版本链，记录该数据的所有历史版本。每个版本包含：

• 数据内容： 该版本的实际值（如字段值）；
• 版本号： 标识版本的生成顺序（如事务 ID、时间戳）；
• 回滚指针（Rollback Pointer）： 指向该版本的前一个版本（用于遍历版本链）。

示例（InnoDB 实现）：
当更新一行数据时，旧版本会被标记为“已删除”（通过 DB_TRX_ID 和 DB_ROLL_PTR），并将旧版本存入回滚段（Undo Log），形成版本链。

新版本则覆盖原数据行的存储位置，但通过版本链关联旧版本。

（2）事务标识：事务 ID（Trx ID）

每个事务启动时会被分配一个唯一的递增事务 ID（trx_id），用于标识事务的时间顺序。事务 ID 是版本可见性判断的核心依据。

（3）快照（Snapshot）

读操作（如 SELECT）不会直接读取当前最新数据，而是基于事务启动时的快照（即该事务启动时所有已提交事务的最大 ID）来决定读取哪个版本。

快照保证了事务的隔离性。

3、可见性规则：如何选择正确的版本？

MVCC 的核心是“可见性判断”：读操作根据自身事务的快照，从版本链中筛选出符合隔离级别要求的版本。不同隔离级别的可见性规则不同，以下以最常用的 读已提交（Read Committed, RC） 和 可重复读（Repeatable Read, RR） 为例：

（1）读已提交（RC）

规则：读操作每次执行时，生成一个新的快照（基于当前所有已提交事务的最大 ID）。
特点：
同一事务内多次读取同一数据，可能看到不同版本（因为快照不断更新）；

解决了“脏读”（不会读取未提交的事务版本），但可能出现“不可重复读”（同一事务内两次读取结果不同）。

（2）可重复读（RR，InnoDB 默认隔离级别）

规则： 事务启动时生成一个固定的快照（基于启动时所有已提交事务的最大 ID），后续所有读操作均使用该快照。

特点：
同一事务内多次读取同一数据，结果始终一致（解决了“不可重复读”）；

但可能读取到“幻读”（其他事务插入的新数据在快照中不存在，导致查询结果行数变化）。

（3）串行化（Serializable）

规则： 强制事务串行执行（通过加锁实现），MVCC 仅作为辅助，实际通过锁避免并发冲突。

4、MVCC 的典型实现（以 MySQL InnoDB 为例）

InnoDB 是最典型的支持 MVCC 的数据库，其实现细节如下：

（1）数据行的隐藏字段

InnoDB 的每行数据隐含 6 个字段（部分关键字段）：

• DB_TRX_ID：最后一次修改该行的事务 ID；
• DB_ROLL_PTR：回滚指针，指向该版本的前一个版本（存储于 Undo Log）；
• DB_ROW_ID：行号（唯一标识，当无主键时自动生成）；
• trx_id：事务 ID（写操作时生成）；
• roll_pointer：回滚指针（指向 Undo Log 中的旧版本）。

（2）Undo Log 的作用

存储旧版本： 当更新数据时，旧版本会被写入 Undo Log，并通过 roll_pointer 链接到新版本；

支持回滚： 事务回滚时，通过 Undo Log 恢复旧版本数据；

支持 MVCC： 读操作通过遍历 Undo Log 中的版本链，找到符合可见性的版本。

（3）读操作的流程（以 RR 隔离级别为例）

事务启动时，记录当前全局的“最大已提交事务 ID”（max_trx_id），作为本次事务的快照；

执行 SELECT 时，遍历数据行的版本链，找到满足以下条件的版本：

• 该版本的 DB_TRX_ID < 当前事务的快照 max_trx_id（已提交）；
• 且该版本的 DB_TRX_ID 不是当前事务自己（避免看到自己未提交的修改）。

5、MVCC 的优缺点

（1）优点

高并发： 读操作不阻塞写操作，写操作不阻塞读操作（通过版本链实现“无锁读”）；

一致性保障： 通过版本控制和可见性规则，支持 RC、RR 等隔离级别，满足大多数业务的一致性需求；

减少锁竞争： 无需为读操作加共享锁，降低了锁冲突概率。

（2）缺点

存储开销： 每个更新操作需生成旧版本并存储到 Undo Log，长期运行可能导致 Undo Log 膨胀（需定期清理）；
维护复杂度： 版本链的管理（如回滚指针、清理旧版本）增加了数据库实现的复杂度；
幻读问题： 在 RR 隔离级别下，MVCC 无法完全解决幻读（需结合间隙锁或临键锁）。

6、总结

MVCC 是数据库实现高并发事务的核心技术，通过维护数据的多版本和可见性规则，实现了“读不阻塞写”的高效并发。

它广泛应用于关系型数据库（如 MySQL InnoDB、PostgreSQL、Oracle），尤其在需要高并发读的场景（如电商订单查询、用户信息读取）中发挥关键作用。

理解 MVCC 有助于优化数据库性能，并合理选择隔离级别以平衡一致性与并发性。

八、分布式数据库和集中式数据库？

1、分布式数据库

位于不同地点的多个计算机通过网络互相连接，共同组成一个完整的、全局的逻辑上集中、物理上分布的大型数据库。

分布式数据库是将物理上分散的多个节点连接起来组成逻辑上统一的数据库，数据被划分成多个子集并分布到不同的节点上，将单个节点的压力分散到多个节点，以实现读写能力扩展。

2、集中式数据库

数据库系统中的数据和处理功能集中在一个中心服务器上，这种模式适用于数据规模比较小，不用按分片存储的业务。它只有普通事务，没有分布式事务。

九、结构化查询语言SQL分类

1、DML【数据操作语言】【Data Manipulation Language】

INSERT
UPDATE
DELETE

2、DDL【数据定义语言】【Data Definition Language】

CREATE
ALTER
DROP
TRUNCATE
RENAME

3、DQL【数据查询语言】【数据查询语言】

SELECT

4、DCL【数据控制语言】【数据库控制语言】

GRANT
REVOKE
DENY

5、TCL【事务控制语言】【事务控制语言】

COMMIT
ROLLBACK
SAVEPOINT

十、其他

1、JDBC：Java Database Connectivity

Java 数据库连接，是 Java 语言中用来规范客户端程序如何来访问数据库的应用程序接口，提供了诸如查询和更新数据库中数据的方法。

2、ODBC：Open Database Connectivity

开放式数据库连接接口，开发人员能够使用相同的 API 来连接、查询和操作不同类型的数据库。

3、API：Application Interface

应用接口，预先定义的接口（如函数、HTTP 接口），或指软件系统不同组成部分衔接的约定。

4、OCI：Open Container Initiative

开放容器倡议

5、OLTP：On-Line Transaction Processing

联机事务处理

6、OLAP：On-Line Analytical Processing

联机分析处理

7、HTAP：Hybrid Transaction Analytical Processing

混合事务负载能力