关系型数据库是我吃饭的家伙。十几年下来，从 SQL 写到手抖到看一眼执行计划就知道问题在哪------这些概念不是背出来的，是一个个生产故障喂出来的。
这篇文章从关系模型、SQL、ACID 事务、并发控制、存储引擎、索引设计、范式理论到高级特性，八个维度把关系型数据库的核心概念捋了一遍。每个概念标了类型标签和难度层级，不管你是刚入行的开发还是老 DBA，碰到了回来翻一翻，应该能省点时间。
一、关系模型基础
本节为基础理论类概念，是理解关系型数据库的起点。关系模型是关系型数据库的理论根基，后续所有特性（SQL、事务、索引）都建立在它的抽象之上。
关系模型 [基础理论]：由Edgar F. Codd于1970年提出的数据模型，用二维表（关系/Relation）来表示数据及数据之间的联系。关系模型的核心思想是将数据与操作分离------数据以关系（表）的形式独立存储，操作通过关系代数或关系演算表达，物理存储对使用者透明。关系模型的理论严格性使其成为数据库领域最具生命力的数据模型------五十余年来，无论上层技术如何变迁，关系模型的抽象始终是数据库设计的核心方法论。
关系（Relation） [基础理论]：关系模型中数据的基本组织单位，对应数据库中的"表"。关系的数学定义：给定一组域D₁, D₂, ..., Dₙ，关系R是这些域的笛卡尔积D₁×D₂×...×Dₙ的一个子集。通俗表述：关系是满足一定约束条件的行（元组）的集合，每一行代表一个实体或联系，每一列代表一个属性。关系的三个核心特性：行无序（关系中元组的顺序无意义）、列无序（属性的顺序由属性名而非位置决定）、元组唯一（不允许出现完全相同的两行）。
元组与属性 [基础理论]：元组（Tuple）是关系中的一行，代表一个实体实例；属性（Attribute）是关系中的一列，代表实体的某个特征。元组=行=记录，属性=列=字段------三组术语在不同上下文中使用，但指代同一概念。
主键与外键 [基础理论]：主键（Primary Key）是唯一标识关系中每个元组的属性或属性组合，必须满足唯一性和非空性。外键（Foreign Key）是一个关系中的属性，引用另一个关系的主键，用于建立关系之间的联系。主键-外键约束是关系型数据库实现参照完整性（Referential Integrity）的核心机制------外键的值必须是引用表中已存在的主键值或为空。
视图 [基础理论]：基于一个或多个基表（Base Table）的查询结果定义的虚拟表。视图不实际存储数据------每次查询视图时，数据库动态执行其定义中的查询语句。视图的价值：封装复杂查询（将多表JOIN、聚合计算封装为一个简单的SELECT from 视图）、安全控制（通过视图限制用户只能访问特定的列或行，而非整个基表）、逻辑数据独立性（基表结构变更时，通过修改视图定义保持上层应用不变）。
关系代数 [基础理论]：操作关系的数学语言，是SQL的理论基础。基本操作：选择（σ，过滤行）、投影（π，选择列）、并（∪）、差（-）、笛卡尔积（×）、重命名（ρ）。组合操作：连接（⨝，从两个关系的笛卡尔积中选取满足连接条件的元组，等同于σ(条件)(R×S)）、交（∩，R∩S=R-(R-S)）、除（÷）。SQL查询在逻辑上等价于关系代数表达式的求值------SQL的SELECT...FROM...WHERE...映射为π...(σ...(×...))的组合。
关系演算 [基础理论]：以谓词逻辑描述查询的非过程化语言，回答"想要什么"而非"怎么获取"。元组关系演算：{t | P(t)}，表示满足谓词P的所有元组t的集合。域关系演算：{<x₁,...,xₙ> | P(x₁,...,xₙ)}，以域变量而非元组为基本单元。SQL的SELECT语句更接近元组关系演算的语法风格------声明期望的结果而非指定执行步骤。
二、SQL语言体系
本节为技术原理类概念（基础-中级），涵盖SQL的分类体系、执行逻辑和核心查询能力。
SQL语言分类 [技术原理]：SQL按功能划分为四个子语言。DDL（Data Definition Language，数据定义语言）：CREATE、ALTER、DROP、TRUNCATE------定义和修改数据库对象结构。DML（Data Manipulation Language，数据操纵语言）：SELECT、INSERT、UPDATE、DELETE------对数据的增删改查。DCL（Data Control Language，数据控制语言）：GRANT、REVOKE------权限的授予和回收。TCL（Transaction Control Language，事务控制语言）：COMMIT、ROLLBACK、SAVEPOINT------事务的提交、回滚和保存点管理。划分四类的实用价值在于：DDL操作通常隐式提交事务、DML操作受事务控制、DCL影响安全模型、TCL控制事务边界------理解分类有助于避免误操作（如在事务中穿插DDL导致事务提前提交）。
SELECT执行顺序 [技术原理]：SQL标准定义的SELECT语句逻辑执行顺序与书写顺序不同。书写顺序：SELECT→FROM→WHERE→GROUP BY→HAVING→ORDER BY→LIMIT。逻辑执行顺序：FROM（确定数据源，执行JOIN）→WHERE（行过滤）→GROUP BY（分组）→HAVING（分组过滤）→SELECT（列投影和表达式计算）→ORDER BY（排序）→LIMIT（行限制）。理解执行顺序的关键意义：WHERE中不能使用SELECT中定义的别名（WHERE在SELECT之前执行），而ORDER BY中可以（ORDER BY在SELECT之后执行）；HAVING中可以引用聚合函数但WHERE中不能（聚合发生在GROUP BY之后）。
JOIN类型 [技术原理]：连接两个表的SQL操作。INNER JOIN（内连接）：只返回两个表中满足连接条件的行。LEFT JOIN（左外连接）：返回左表所有行，右表无匹配时以NULL填充。RIGHT JOIN（右外连接）：返回右表所有行，左表无匹配时以NULL填充。FULL OUTER JOIN（全外连接）：返回两表所有行，无匹配侧以NULL填充。CROSS JOIN（交叉连接）：返回两表的笛卡尔积。SELF JOIN（自连接）：表与自身连接。
子查询 [技术原理]：嵌套在另一个查询中的SELECT语句。按位置分：SELECT子查询（标量子查询，必须返回单行单列）、FROM子查询（派生表，必须有别名）、WHERE子查询。按与外部查询的关系分：非关联子查询（先独立执行子查询，再执行外部查询）、关联子查询（子查询引用外部查询的列，每处理一行外部查询就执行一次子查询------性能通常较差）。按返回值分：标量子查询（单行单列）、行子查询（单行多列）、列子查询（多行单列------配合IN/ANY/ALL使用）。
窗口函数 [技术原理]：在保持原始行粒度的情况下，基于"窗口"（一组与当前行相关的行）进行聚合计算。基本语法：函数名() OVER (PARTITION BY 分组列 ORDER BY 排序列 ROWS/RANGE 窗口范围)。常用窗口函数：ROW_NUMBER()（行号）、RANK()（排名，并列跳号）、DENSE_RANK()（排名，并列不跳号）、LAG/LEAD()（前/后N行的值）、SUM/AVG/COUNT()作为窗口聚合（计算滚动累计值）。窗口函数在需要保留明细行的同时进行聚合计算的场景下（如求各月销售额的累计值、各部门内部的员工排名）替代自连接和复杂子查询。
CTE [技术原理]：Common Table Expression，用WITH子句定义的临时命名结果集，在后续查询中如同普通表一样引用。CTE使复杂查询可读性大幅提升------将多层嵌套子查询拆解为顺序的、命名的逻辑步骤。CTE递归：CTE定义中引用自身（WITH RECURSIVE），用于处理树形/图结构的遍历（如组织架构层级、物料BOM展开）。CTE作用于单一SQL语句，语句执行完毕后即释放------不同于视图（持久化定义）和临时表（持久化数据）。
三、ACID事务
本节为技术原理类概念（中级），是关系型数据库区别于大多数NoSQL系统的核心能力。
原子性（Atomicity） [技术原理]：事务中的所有操作要么全部执行成功，要么全部不执行------不存在部分执行、部分失败的状态。数据库通过Undo日志实现原子性：事务执行过程中，将所有修改前的旧值记录到Undo日志，如果事务需要回滚（显式ROLLBACK或系统崩溃后的恢复），通过Undo日志将数据逐条恢复到修改前的状态。原子性的工程含义：提交失败的事务对数据库状态没有任何影响，上层应用可以安全地重试整个事务而无需处理中间状态。
一致性（Consistency） [技术原理]：事务执行前后，数据库从一个一致状态转变到另一个一致状态。一致状态由所有已定义的完整性约束（主键约束、外键约束、CHECK约束、NOT NULL约束、触发器规则）共同定义。一致性是ACID中唯一由用户定义而非数据库自动保证的属性------数据库负责执行约束检查（违反约束的操作被拒绝），但无法判断约束定义本身是否"业务正确"。
隔离性（Isolation） [技术原理]：并发执行的事务之间互相不可见，每个事务感觉自己是数据库中唯一运行的事务。隔离性是ACID中与性能最直接冲突的属性------严格隔离需要串行执行事务，性能极差；降低隔离级别可提升并发性能，但引入一致性问题。隔离性通过并发控制机制实现（锁、MVCC等），不同隔离级别提供不同强度的隔离保证。
持久性（Durability） [技术原理]：已提交的事务对数据库的修改是永久的，即使系统崩溃也不丢失。持久性通过WAL（Write-Ahead Logging，预写日志）实现：事务提交时，先将所有修改的日志记录强制刷写到磁盘，确认刷写成功后事务才算提交------如果系统在数据页写入磁盘前崩溃，恢复时通过重放WAL日志重建已提交的数据修改。持久性的工程保障还包括：日志写入磁盘而非操作系统缓存（fsync/fdatasync调用）、备用电源防止磁盘缓存丢失、异地日志备份防止机房级灾难。
隔离级别 [技术原理]：SQL标准定义的四个事务隔离级别，从低到高隔离程度递增、并发性能递减。读未提交（Read Uncommitted）：允许读取未提交的数据（脏读），基本无实用场景。读已提交（Read Committed）：只能读取已提交的数据，但同一事务内两次读取同一行可能得到不同结果（不可重复读）。可重复读（Repeatable Read）：同一事务内多次读取同一行结果一致，但可能读到新增的行（幻读）。串行化（Serializable）：事务按串行顺序执行，完全隔离，无并发异常。不同数据库的默认隔离级别和实现方式不同------PostgreSQL默认为读已提交，通过MVCC实现；Oracle默认为读已提交，同样通过MVCC和Undo实现；MySQL InnoDB默认可重复读，通过MVCC+Next-Key Lock结合防止幻读。
四、并发控制
本节为技术原理类概念（中级-进阶），涵盖多事务并发场景下的数据一致性和性能协调机制。
MVCC [技术原理·进阶]：Multi-Version Concurrency Control，多版本并发控制。核心思想：每次写操作不直接覆盖原数据，而是创建数据的新版本，每个事务看到的是数据的某个一致性快照（snapshot）。MVCC实现了"读不阻塞写、写不阻塞读"------读事务读取旧版本，不需要加锁等写事务释放；写事务创建新版本，不需要等待读事务完成。MVCC通过事务ID（XID）和可见性规则判断：当前事务ID、创建该版本的事务ID（xmin）、删除/更新该版本的事务ID（xmax），加上事务提交状态的判断，决定一个数据版本对当前事务是否可见。PostgreSQL、Oracle、MySQL InnoDB均基于MVCC实现事务隔离。
锁机制 [技术原理]：数据库并发控制的传统方式。共享锁（S锁/读锁）：允许多个事务同时持有，持有期间其他事务可以读但不能写。排他锁（X锁/写锁）：只允许一个事务持有，持有期间其他事务既不能读也不能写。意向锁（IS/IX锁）：表级别的锁，表示事务计划在更细粒度（行）上加S或X锁------用于快速判断表上是否有相互冲突的锁而无需遍历所有行。行锁vs表锁：行锁粒度细并发高但锁管理开销大，表锁粒度粗并发低但开销小。锁升级（Lock Escalation）：当行锁数量超过阈值，数据库自动将多行锁升级为单表锁以降低锁管理开销（常见于SQL Server）。
死锁检测 [技术原理]：当两个或多个事务互相等待对方持有的锁，形成循环等待时触发。死锁检测器周期性扫描等待图（Wait-for Graph）中的环，检测到环后选择一个事务作为"死锁牺牲品"回滚，释放其持有的锁以打破等待环。牺牲品的选择策略：通常选择回滚代价最小的事务（修改行数最少、已持有锁时间最短的事务）。预防死锁的工程手段：统一加锁顺序（所有事务按相同顺序访问资源）、缩短事务持有锁的时间（将与锁无关的操作移出事务）、使用适当的隔离级别（降低不必要的锁需求）。
乐观锁与悲观锁 [技术原理]：两种并发控制策略。悲观锁：假设冲突大概率发生，操作前先加锁，操作完成后释放------适合高冲突场景（如秒杀库存扣减）。乐观锁：假设冲突概率低，操作不加锁，提交时检查数据版本是否被并发修改过------如果版本已变则回滚重试，如果版本未变则提交成功。乐观锁通常通过版本号字段（UPDATE ... SET version=version+1 WHERE version=旧版本号）或时间戳实现。乐观锁适合读多写少、冲突率低的场景；悲观锁适合高冲突核心数据场景。
五、存储引擎
本节为技术原理类概念（进阶），深入数据库内部的数据组织和持久化机制。
B+Tree [技术原理·进阶]：关系型数据库中最主流的索引和数据存储结构。B+Tree是多路平衡搜索树------所有数据存储在叶子节点（叶子节点形成有序链表），内部节点仅存储索引键值用于导航。B+Tree的高度通常在3-4层（可索引数亿行数据），每次查找只需3-4次磁盘读取。叶子节点的有序链表支持高效的范围扫描（找到起始位置后沿链表顺序读取即可）。B+Tree的节点大小通常对齐操作系统页大小（4KB/8KB/16KB），一次磁盘I/O读取一个完整节点。
LSM-Tree [技术原理·进阶]：Log-Structured Merge-Tree，基于顺序写入优化的存储结构。数据先写入内存中的MemTable（有序结构，通常为跳表或红黑树），MemTable写满后整体刷写到磁盘形成一个不可变的SSTable文件。读操作需要查询MemTable和所有SSTable（可能数十个），通过布隆过滤器（Bloom Filter）快速判断每个SSTable中是否可能包含目标Key以跳过不必要的磁盘读取。后台Compaction进程定期合并多个SSTable，消除重复和已删除的Key，维持读性能。LSM-Tree将随机写转化为顺序写，写入性能远优于B+Tree；但读放大（一次读需查询多层）和写放大（Compaction重写数据）是性能代价。LSM-Tree是RocksDB、LevelDB、Cassandra、HBase的存储基础。
数据页与缓冲池 [技术原理·进阶]：数据库的最小I/O单位是页（Page，通常8KB/16KB），读写磁盘以页为单位。缓冲池（Buffer Pool）是数据库在内存中缓存数据页的区域------读请求先查缓冲池（命中则无需磁盘I/O），写请求先修改缓冲池中的页（标记为脏页），由后台Checkpoint进程异步将脏页刷写到磁盘。缓冲池的页替换策略通常为LRU（最近最少使用）或Clock的变体------根据数据页的访问频率和最近访问时间决定淘汰优先级。
WAL日志 [技术原理·进阶]：Write-Ahead Logging，预写日志。核心规则：在将数据页的修改写入磁盘之前，必须先将对应的日志记录（包含修改前后的值）写入磁盘日志文件。WAL保证Crash安全------系统崩溃后通过重放日志恢复已提交事务的数据修改。WAL日志是顺序追加写入，性能远优于数据页的随机写入（这正是WAL设计的关键优势------将随机写转化为日志的顺序写，再通过Checkpoint将日志中的修改批量合并到数据页的随机写）。Redo日志（记录修改后的新值，用于重放已提交事务）和Undo日志（记录修改前的旧值，用于回滚未提交事务）是WAL日志的两种内容类型。
六、索引设计
本节为技术原理与工程实践类概念，涵盖索引的类型、原理和优化决策。
聚簇索引与非聚簇索引 [技术原理]：聚簇索引（Clustered Index）：数据行按索引键的物理顺序存储，一个表只能有一个聚簇索引（因为数据只能按一种顺序物理存放）。主键默认创建聚簇索引。通过聚簇索引查找数据无需回表------索引的叶子节点就是数据行本身。非聚簇索引（Non-Clustered Index/Secondary Index）：索引结构与数据行分开存储，叶子节点存储索引键和指向数据行的指针（或主键值）。通过非聚簇索引查找数据需要回表------先查索引找到主键值，再通过主键值查聚簇索引获取完整数据行（除非索引包含了查询所需的所有列------即覆盖索引）。
联合索引 [技术原理]：在多个列上创建的复合索引，索引键由多列值组合而成。联合索引的核心规则------最左前缀原则：查询条件必须从索引的最左列开始连续匹配，索引才能被使用。例如索引 (A, B, C) 可用于 WHERE A=1 和 WHERE A=1 AND B=2，但无法用于 WHERE B=2（跳过了最左列A）和 WHERE A=1 AND C=3（跳过了中间列B------部分数据库可做索引跳跃扫描但效率较低）。联合索引的列顺序设计是索引优化中最关键的决策------将选择性最高的列放在最左可以最大限度过滤数据。
覆盖索引 [技术原理]：查询所需的所有列都包含在索引中，无需回表即可完成查询。实现方式：创建索引时使用INCLUDE子句（将非索引键的列也存储在索引叶子节点中），或利用联合索引包含查询所需的全部列。覆盖索引是消除回表开销最直接的手段------在OLTP场景中，回表意味着额外的随机磁盘I/O。EXPLAIN输出中"Using index"表示使用了覆盖索引。
索引下推 [技术原理]：Index Condition Pushdown（ICP），将WHERE条件中对索引列的部分过滤逻辑下推到存储引擎层执行，减少返回给SQL层的行数和回表次数。例如 WHERE name LIKE '张%' AND age>18，在name索引上扫描时，存储引擎在扫描索引的过程中就过滤age>18，不符合条件的行不回表、不返回SQL层。索引下推是MySQL 5.6引入的重要优化，对于联合索引中非首列的条件过滤效果显著。
索引失效场景 [工程实践]：常见导致索引无法使用的SQL写法。对索引列使用函数或表达式：WHERE DATE(create_time)='2026-01-01' 使索引失效，应写为 WHERE create_time>='2026-01-01' AND create_time<'2026-01-02'。隐式类型转换：VARCHAR列与整数比较导致索引失效。使用NOT、!=、<> 等否定条件通常导致索引失效（优化器选择全表扫描）。LIKE以通配符开头：LIKE '%keyword' 导致索引失效，LIKE 'keyword%' 可以使用索引。使用OR连接非索引列：使索引部分列的条件也退化。
七、范式设计
本节为基础理论与工程实践类概念，是数据库表结构设计的核心方法论。
第一范式（1NF） [基础理论]：关系中每个属性（列）的值都是原子性的（不可再分）。违反1NF的典型场景：一个列中存储逗号分隔的多个值（如tags列存储"Java,Python,Go"）、一个列中存储JSON结构并按内部字段查询（如果JSON被当作文本查询则违反，如果是JSON类型且有索引支持则不违反）。1NF确保每一列只有单一值，是后续高级范式的基础。
第二范式（2NF） [基础理论]：满足1NF，且每个非主键属性完全函数依赖于整个主键（而非主键的一部分）。2NF只对复合主键的表有意义------单列主键的表自动满足2NF。违反2NF的典型场景：复合主键(学生ID, 课程ID)，但表中存在"学生姓名"字段------"学生姓名"只依赖于主键的一部分（学生ID），而非整个主键(学生ID,课程ID)。解决方案：将部分依赖的属性拆分到单独的表（学生表包含学生ID和学生姓名）。
第三范式（3NF） [基础理论]：满足2NF，且不存在非主键属性对主键的传递函数依赖。传递函数依赖：主键→字段A→字段B（A和B都不是主键）。违反3NF的典型场景：订单表包含"客户ID"和"客户姓名"------主键→客户ID→客户姓名，形成传递依赖。解决方案：将客户姓名移到客户表中，订单表只保留客户ID。3NF是大多数OLTP系统表设计的合理目标------消除数据冗余和更新异常，同时不过度拆分导致查询需要大量JOIN。
BCNF [基础理论]：Boyce-Codd范式，3NF的加强版，要求每个非平凡函数依赖的决定因素都是超键（候选键的超集）。BCNF覆盖了3NF在"存在多个候选键且候选键之间有重叠属性"场景下的遗漏。在绝大多数数据库设计中，3NF已足够------BCNF和3NF的差异场景在实践中较少出现。
反范式化 [工程实践]：故意引入冗余数据以提升查询性能的设计策略。反范式化的典型操作：在多对多关系的关联表中冗余存储维度字段（如订单明细表同时存储商品ID和商品名称------避免每次查询都JOIN商品表）、预计算并存储聚合值（如在用户表中冗余存储订单总金额------避免频繁COUNT+SUM）。反范式化的代价：写入时需要维护冗余数据的一致性（通常由应用层或触发器保证）、存储空间增加。反范式化必须在性能收益和维护成本的权衡中有依据地进行。
ER模型 [基础理论]：实体-关系模型（Entity-Relationship Model），数据库概念设计的图形化表示方法。实体（Entity）用矩形表示，代表现实世界中的对象（如学生、课程）。属性（Attribute）用椭圆表示，代表实体的特征。关系（Relationship）用菱形表示，代表实体间的联系。关系的基数约束：一对一（1:1）、一对多（1:N）、多对多（M:N）。ER模型是需求分析到数据库物理设计的中间步骤------先画ER图对齐业务理解，再转换为一组满足3NF的表结构。
八、高级特性
本节为技术原理与架构设计类概念，涵盖关系型数据库的高阶功能和特殊能力。
分区表 [技术原理]：将大表在物理存储层面拆分为多个子表（分区），逻辑上仍表现为一张完整表。分区方式：范围分区（按日期、ID范围）、列表分区（按枚举值如地区代码）、哈希分区（按哈希值分散数据到各分区）。分区带来的收益：分区裁剪（查询仅扫描相关分区而非全表）、高效的数据生命周期管理（按日期分区，删除过期数据直接DROP分区而非逐行DELETE，秒级完成）、分区级别的并行扫描。分区键的选择需要与查询模式匹配------如果最频繁的查询条件无法利用分区裁剪，分区的价值大打折扣。
物化视图 [技术原理]：查询结果的物理存储副本（区别于普通视图的动态计算）。物化视图适合复杂聚合查询频繁但底层数据变更不频繁的场景------预先计算并存储聚合结果，查询时直接读取存储结果而非实时聚合。代价是物化视图与基表不同步------需要定义刷新策略：ON COMMIT（每次基表修改后自动刷新，保证实时一致但写性能受影响）、ON DEMAND（手动或定时刷新，读取可能不是最新数据）。物化视图可创建独立索引，进一步提升查询性能。
触发器 [技术原理]：在特定事件（INSERT/UPDATE/DELETE）发生前或发生后自动执行的存储过程。触发时机：BEFORE（操作前触发，可修改待写入的数据）、AFTER（操作后触发，用于级联更新审计日志等附加操作）、INSTEAD OF（替代操作，主要用于视图的写入）。触发器类型：语句级触发器（每条SQL触发一次）和行级触发器（每影响一行触发一次）。触发器的风险：隐藏的逻辑（开发者可能不知道触发器的存在，导致排查问题时迷惑）、级联触发（一个触发器的操作触发另一个触发器）、性能影响（在批量写入场景下，行级触发器的累积开销可能极大）。
存储过程 [技术原理]：预编译并存储在数据库服务器上的一组SQL语句和控制逻辑，可通过CALL语句调用执行。存储过程的优势：减少网络往返（一次CALL替代多次SQL传输）、预编译（首次执行后生成执行计划缓存，后续调用复用）、封装业务逻辑（将复杂的数据操作逻辑封装在数据库侧，应用层通过简洁接口调用）。存储过程的劣势：业务逻辑与数据库耦合（迁移到其他数据库时存储过程需全部重写）、版本管理和CI/CD困难（存储过程不属于应用代码仓库的一部分）、调试和测试不便（缺乏IDE级别的调试支持）。
CTE递归 [技术原理·进阶]：WITH RECURSIVE定义的递归公共表表达式，用于遍历树形或图结构数据。基本结构：递归CTE由两部分UNION ALL组成------锚定成员（初始查询，提供递归起点）和递归成员（引用CTE自身的查询）。终止条件：递归成员不再产生新行时递归停止。典型应用：组织架构树（从根节点递归向下查找所有下属）、物料BOM展开（从成品递归向下展开所有子物料）、图的最短路径。递归深度通常受系统参数限制（如默认100层），防止无限递归耗尽资源。
最后
关系型数据库搞了五十多年，核心理论没怎么变过------关系模型、ACID、索引、范式这些，到今天依然是根基。变的是具体实现，不变的是你把基础打扎实了，换哪个产品都能快速上手。就比如金仓 KingbaseES 在关系型数据库这块对 SQL 标准支持得很全面，ACID 事务、MVCC、多种存储引擎这些企业级能力都有，兼容 Oracle 和 MySQL 生态，迁移过来的兄弟上手很快。
这篇文章你不需要全背。做开发的重点看第一部分关系模型和第二部分 SQL，做 DBA 的重点看第三部分事务和第四部分并发控制，做优化的重点看第六部分索引。剩下的碰到了再查。
DBA小马哥，一线数据库运维老兵。用真实项目故事讲技术干货，踩过的坑都帮你填平了。
声明：本文技术内容基于公开资料和行业实践整理，仅供参考。不同数据库产品在具体功能实现上存在差异，请以实际产品文档为准。