Database on 纪伟的个人博客

数据库系列（十）：数据存储全景 — OLTP / OLAP / HTAP / 数仓 / Lakehouse 一图看懂

Mon, 15 Jun 2026 08:00:00 +0800

写在前面

经过 9 篇深入关系数据库的底层原理，本文作为系列收官，跳出 RDBMS，俯瞰整个数据存储生态。

本文要回答：

OLTP、OLAP、HTAP、数仓、Lakehouse、NoSQL 都是干什么的？怎么选？Snowflake / BigQuery / TiDB / Iceberg / Doris / ClickHouse 在生态中各处于什么位置？

一、数据存储的分类全景

1.1 一张总图

                          数据存储生态
                              │
       ┌──────────────────────┼──────────────────────┐
       │                      │                      │
   关系数据库               NoSQL                  大数据生态
   (RDBMS)                  (非关系)               (数据湖/数仓)
       │                      │                      │
   ┌───┴───┐            ┌─────┴─────┐          ┌────┴─────┐
   │       │            │           │          │          │
  OLTP   OLAP          键值/列族  文档/图形   数据仓库   数据湖
  MySQL  Doris         Redis     MongoDB    Snowflake  S3/HDFS
  PG     ClickHouse    Cassandra Neo4j      BigQuery
  Oracle StarRocks     DynamoDB
        Snowflake

   横切维度：
   ───────────────────────────────
   HTAP       TiDB / CockroachDB / SingleStore
   Lakehouse  Iceberg / Hudi / Delta / Paimon
   时序       InfluxDB / TimescaleDB / Prometheus
   图         Neo4j / JanusGraph / NebulaGraph

1.2 分类维度

按数据模型：
  - 关系：MySQL / PG / Oracle
  - 键值：Redis / DynamoDB
  - 列族：Cassandra / HBase / Bigtable
  - 文档：MongoDB / CouchDB
  - 图：Neo4j / Dgraph
  - 时序：InfluxDB / TimescaleDB
  - 全文：Elasticsearch

按负载类型：
  - OLTP（联机事务处理）：高并发短事务
  - OLAP（联机分析处理）：长查询聚合
  - HTAP（混合）：两者兼顾

按部署形态：
  - 单机：传统 RDBMS
  - 分布式：Cassandra / HBase / Spanner
  - 云原生：Snowflake / BigQuery / Aurora
  - 一体机：Oracle Exadata / Teradata

二、OLTP（联机事务处理）

2.1 特征

OLTP 工作负载：
  - 大量短事务（毫秒级）
  - 高并发（数千 QPS）
  - 按主键点查、按索引范围查
  - 严格 ACID
  - 行存为主

典型业务：
  - 电商交易
  - 银行账户
  - 用户登录
  - 在线游戏

2.2 代表产品

产品	特点
MySQL	互联网首选，简单稳定
PostgreSQL	复杂查询强，扩展丰富
Oracle	企业级标杆，商用
SQL Server	微软生态首选
Aurora	AWS 的"云原生 MySQL/PG"，存算分离
TiDB	兼容 MySQL 协议的 HTAP
CockroachDB	兼容 PG 协议的全球分布式

2.3 OLTP 的边界

OLTP 不擅长：
  - 跨表大规模聚合（数据分析）
  - 千万行以上的范围扫描
  - 复杂的窗口函数
  - 海量历史数据存储

→ 这些场景交给 OLAP / 数据仓库

三、OLAP（联机分析处理）

3.1 特征

OLAP 工作负载：
  - 少量长查询（秒~分钟级）
  - 大范围扫描
  - 多维聚合（GROUP BY 多列）
  - 容忍弱一致性
  - 列存为主

典型业务：
  - BI 报表
  - 实时大屏
  - 用户行为分析
  - 日志检索

3.2 代表产品

传统 OLAP（MPP）：
  - Teradata（一体机）
  - Greenplum（PG 衍生）
  - Vertica（列存）
  - Neteeza（IBM，已停）

新一代 OLAP：
  - ClickHouse：极致单表性能
  - Apache Doris：开箱即用的实时数仓（详见本博客 Doris 系列）
  - StarRocks：Doris 商业升级，联邦查询强
  - Apache Druid：时序 + 实时分析
  - Apache Pinot：LinkedIn 出品，类似 Druid

3.3 OLAP 引擎坐标

                高并发查询
                    ↑
                    │
            Doris   │   Druid
                    │   Pinot
   ─────────────────┼──────────────→  实时性
                    │
            ClickHouse
                    │
                    │   Greenplum
                    │   Vertica
                    ↓
                海量批处理

本博客已发布的 OLAP 笔记（坐标定位，不再展开）：
  - Elasticsearch 系列：搜索引擎 + 实时分析
  - Doris 系列：实时数仓 / OLAP
  - Redis 系列：缓存（KV，不是 OLAP 但常配合）

四、HTAP（混合负载）

4.1 HTAP 的动机

传统架构：
  OLTP（MySQL）→ CDC / ETL → OLAP（ClickHouse / Hive）
  问题：
  - 数据延迟（T+1 或分钟级）
  - 数据冗余（多套存储）
  - ETL 维护复杂
  - 一致性难保证

HTAP 目标：
  一个数据库同时扛 OLTP + OLAP
  - 实时（无 ETL）
  - 单一数据源
  - 简化架构

4.2 HTAP 的实现思路

思路 1：行列双存（Oracle IMCS / TiDB TiFlash）
  - 行存（用于 OLTP）+ 列存（用于 OLAP）
  - 后台同步两份

思路 2：单存优化（SingleStore）
  - 一种"通用"存储同时支持两种负载

思路 3：存算分离 + 多引擎（Snowflake / BigQuery）
  - 计算层动态选择执行引擎

4.3 代表产品

产品	特点
TiDB	MySQL 兼容，TiKV（行）+ TiFlash（列）
CockroachDB	PG 兼容，全球分布式
SingleStore	MemSQL 改名，统一存储
Oracle 12c+	In-Memory 选项
SQL Server	Columnstore + 行存
OceanBase	阿里，金融级 HTAP

4.4 HTAP 的代价

代价：
  - 写入放大（双存）
  - 资源占用高
  - 调优复杂（两套优化）
  - 不可能同时极致优化两种负载

适用场景：
  - 中等规模（TB 级）
  - 实时分析需求强
  - 不想维护 ETL 链路

不适用：
  - 超大规模 OLAP（PB 级）→ 单独的 OLAP 引擎
  - 极致 OLTP 性能 → 单纯的 OLTP

五、数据仓库（Data Warehouse）

5.1 数仓的定义

数据仓库（Inmon 定义）：
  - 面向主题
  - 集成
  - 时变
  - 非易失

特点：
  - 来自多个源系统的统一数据存储
  - 用于决策支持、报表、分析
  - 历史 ETL 数据沉淀

5.2 数仓的演进

第一代：单机数据库 + OLAP 工具（90s）
  - Oracle / SQL Server + Hyperion / BO

第二代：MPP 数据仓库（2000s）
  - Teradata / Greenplum / Vertica
  - Shared-Nothing 架构
  - 性能远超单机

第三代：Hadoop / Hive（2010s）
  - 基于 HDFS
  - 便宜但慢
  - 离线数仓 T+1

第四代：云原生数仓（2015+）
  - Snowflake / BigQuery / Redshift
  - 存算分离
  - 弹性扩展
  - 按用量付费

第五代：实时数仓 / Lakehouse（2020+）
  - Doris / StarRocks
  - Iceberg / Hudi / Delta
  - 实时 + 离线一体

5.3 数仓的经典分层

数据分层（Kimball 模型）：

  ODS（原始数据层）：源系统原始数据
       │
       │ 清洗、转换
       ▼
  DWD（明细数据层）：标准化的事实明细
       │
       │ 轻度聚合
       ▼
  DWS（汇总数据层）：按主题汇总
       │
       │ 业务加工
       ▼
  ADS（应用数据层）：报表、大屏、API 数据

ETL 工具：Hive / Spark / Flink / dbt

5.4 云原生数仓

Snowflake（2015）：
  - 完全 SaaS，无运维
  - 存算分离（S3 + 计算）
  - 多云（AWS / Azure / GCP）
  - 按用量付费
  - 自动扩展

BigQuery（2010）：
  - Google 内部 Dremel 开源
  - Serverless
  - PB 级查询
  - 标准 SQL

Redshift（2013）：
  - AWS 的 MPP 数仓
  - ParAccel 改造
  - 性价比好

Azure Synapse：
  - 微软的云数仓
  - 整合 Power BI / ADF

六、Lakehouse（湖仓一体）

6.1 Lakehouse 的诞生

传统架构痛点：
  数据湖（HDFS/S3 + 文件）：
  - 便宜，能存所有数据
  - 但没有事务、没有 schema 强制
  - "数据沼泽"

  数据仓库：
  - 强 schema、ACID
  - 但贵、闭环

Lakehouse：把数据仓库的特性（ACID、schema、查询）带到数据湖上

6.2 Lakehouse 表格式

开源三剑客 + 一匹黑马：

Apache Iceberg（Netflix）：
  - 表格式
  - ACID 事务（基于快照）
  - 时间旅行
  - Schema 演化
  - 分区演化
  - Spark / Flink / Trino / Doris / StarRocks 都支持

Apache Hudi（Uber）：
  - 表格式 + 数据管理
  - 支持 Upsert（更新插入）
  - 增量查询
  - CDC 友好

Delta Lake（Databricks）：
  - Databricks 出品
  - ACID 事务
  - 与 Spark 深度集成
  - 商业版有优化

Apache Paimon（Flink 表格）：
  - 流批一体
  - Flink 主推
  - 中国社区活跃（阿里主导）

6.3 四种格式对比

维度	Iceberg	Hudi	Delta	Paimon
出身	Netflix	Uber	Databricks	Flink
主推场景	分析	CDC / 增量	Spark 生态	流批一体
Schema 演化	✅ 强	✅	✅	✅
时间旅行	✅	✅	✅	✅
ACID	✅	✅	✅	✅
Upsert 性能	中	强	中	强
生态支持	最广	中	Spark 强	Flink 强

6.4 Lakehouse 架构

       ┌────────────────────────────────────────┐
       │         查询引擎（计算层）              │
       │   Spark / Flink / Trino / Doris        │
       └──────────────────┬─────────────────────┘
                          │
                          │ 读 / 写表格式
                          ▼
       ┌────────────────────────────────────────┐
       │       表格式（元数据 + 事务）           │
       │   Iceberg / Hudi / Delta / Paimon      │
       └──────────────────┬─────────────────────┘
                          │
                          │ 元数据指向数据文件
                          ▼
       ┌────────────────────────────────────────┐
       │         对象存储（存储层）              │
       │   S3 / OSS / HDFS / Azure Blob         │
       └────────────────────────────────────────┘

特点：
  - 存储、表格式、计算解耦
  - 每层可独立选择
  - 多引擎共享同一份数据
  - 弹性扩展

七、NoSQL 速览

7.1 NoSQL 的"非"关系

NoSQL = Not Only SQL
不同 NoSQL 解决不同问题：

KV（键值）：
  - Redis / Memcached（内存）
  - DynamoDB / etcd（持久）
  特点：极致性能，简单数据模型

列族（Wide Column）：
  - Cassandra / HBase / ScyllaDB
  特点：超高写入吞吐，海量稀疏数据

文档（Document）：
  - MongoDB / CouchDB
  特点：JSON 数据，灵活 schema

图（Graph）：
  - Neo4j / Dgraph / NebulaGraph
  特点：关系密集数据（社交、推荐）

时序（Time Series）：
  - InfluxDB / TimescaleDB / Prometheus
  特点：时间戳索引，写入密集

全文检索：
  - Elasticsearch / OpenSearch / Solr
  特点：倒排索引，文本搜索（详见本博客 ES 系列）

7.2 CAP 定理

CAP 定理（Brewer）：
  - C（Consistency）：一致性
  - A（Availability）：可用性
  - P（Partition tolerance）：分区容忍

只能选两个（实际上 P 必选，所以是 C vs A）：

CP：Cassandra（默认）/ HBase / MongoDB
AP：CouchDB / DynamoDB（默认）

不同选择对应不同业务场景：
  - 银行 / 关键业务：CP（保证一致）
  - 社交 / 推荐：AP（容忍最终一致）

7.3 BASE 与最终一致性

BASE = Basically Available + Soft state + Eventually consistent
对应 ACID 的对立面

最终一致性的典型场景：
  - 微信朋友圈：你刚发的动态，朋友可能延迟 1 秒看到
  - 电商库存：超卖允许（事后对账）
  - 用户画像：分钟级同步

八、选型决策树

8.1 按场景选型

Q1：你的负载是 OLTP 还是 OLAP？
  → OLTP：看 Q2
  → OLAP：看 Q4
  → 两者都有：看 Q6（HTAP）

Q2：数据规模？
  → 单库 < 5TB：MySQL / PostgreSQL
  → 单库 > 5TB 但可控：分库分表（ShardingSphere / Vitess）
  → 单库压不下：分布式数据库（TiDB / CockroachDB）

Q3：业务复杂度？
  → 简单 CRUD：MySQL
  → 复杂查询 / JSON / GIS：PostgreSQL
  → 微软生态：SQL Server
  → 预算充足 / 关键业务：Oracle

Q4：查询模式？
  → 实时多维分析：Doris / StarRocks
  → 单表极致性能：ClickHouse
  → 时序 + 分析：Druid / Pinot
  → 文本搜索：Elasticsearch

Q5：数据规模 + 实时性？
  → PB 级 + 离线：Hive / Spark on S3
  → PB 级 + 实时：Lakehouse（Iceberg / Hudi）
  → TB 级 + Serverless：Snowflake / BigQuery

Q6：HTAP 评估？
  → 数据规模 TB 级 + 不想维护 ETL：TiDB / CockroachDB
  → 关键业务 + 预算充足：Oracle IMCS / OceanBase

8.2 实战决策

典型组合：

  小型 SaaS（百万级用户）：
    MySQL（OLTP）+ Redis（缓存）+ Elasticsearch（搜索）

  互联网公司（亿级用户）：
    MySQL 分片 + Redis 集群 + Doris（实时数仓）+ Hive（离线）

  传统企业（关键业务）：
    Oracle RAC（核心）+ SQL Server（部门）+ Power BI

  数据驱动公司：
    PostgreSQL（业务）+ Snowflake（数仓）+ dbt（ETL）

  IoT / 监控：
    TimescaleDB / InfluxDB（时序）+ Grafana（可视化）

  推荐系统：
    MySQL / TiDB（OLTP）+ Neo4j（图）+ ClickHouse（行为分析）

九、回顾与系列总结

9.1 本系列 10 篇回顾

篇	主题	核心知识
1	总览	一行 UPDATE 串联的 10 个原理子系统
2	存储引擎	物理页 + HEAP/IOT + 行存/列存
3	索引	B+ 树 + 聚集/非聚集 + 失效坑
4	事务 ACID	Undo（A）+ Redo（D）+ WAL
5	MVCC	多版本 + 可见性 + 隔离级别
6	锁	Record/Gap/Next-Key + 死锁检测
7	日志恢复	ARIES + Checkpoint + PITR
8	复制高可用	物理/逻辑复制 + MGR/AlwaysOn/ADG
9	SQL 优化器	CBO + 统计信息 + 执行计划
10	全景	OLTP/OLAP/HTAP/数仓/Lakehouse

9.2 关键认知

1. 关系数据库的"原理"是共通的
   - 四大家解决同一组问题
   - 只是命名和细节不同
   - 学透一个，迁移成本很低

2. 选型看场景
   - 没有最好的数据库
   - 只有最合适的数据库
   - 选错比"不会用"代价大

3. 底层原理决定上限
   - 性能调优必须懂底层
   - 排错必须懂底层
   - 升级迁移必须懂底层

9.3 后续学习路径

本系列是"原理地图"，深入某一项可看：

  存储引擎：
    《Database Internals》（Alex Petrov）
    《Designing Data-Intensive Applications》（Martin Kleppmann）

  事务：
    《Transaction Processing》（Jim Gray）
    《Database System Concepts》（Silberschatz）

  PostgreSQL：
    《The Internals of PostgreSQL》
    官方文档"Internals"章节

  MySQL：
    《MySQL 实战 45 讲》（林晓斌）
    《High Performance MySQL》

  分布式：
    《Designing Data-Intensive Applications》
    Raft Paper / Paxos Paper

  数仓 / Lakehouse：
    Kimball《数据仓库工具箱》
    Iceberg / Hudi / Delta 官方文档

9.4 系列正式完结

本系列 10 篇覆盖：

关系数据库的核心原理（存储、索引、事务、MVCC、锁、日志、复制、SQL）
四大数据库（Oracle / SQL Server / MySQL / PostgreSQL）的横向对比
数据存储生态全景（OLTP / OLAP / HTAP / 数仓 / Lakehouse / NoSQL）

希望这份笔记对你建立系统的数据库知识体系有所帮助。后续如需深入某个方向，欢迎继续探索。

记住三句话：
  1. 数据库原理是一张网，不是一条线
  2. 选型 = 场景 + 约束 + 经验，没有标准答案
  3. 学无止境——技术会过时，原理不会

完。

数据库系列（九）：SQL 方言与查询优化器 — 为什么同样的 SQL 性能差 10 倍

Sun, 14 Jun 2026 23:00:00 +0800

写在前面

前面 8 篇都在讲存储与事务的底层机制，本文跳出"物理层"，进入"逻辑层"——SQL 方言与查询优化器。

本文要回答：

同样的 SQL，为什么在 PostgreSQL 比 MySQL 快 10 倍？RBO 和 CBO 有什么区别？统计信息为什么这么重要？为什么参数嗅探是个坑？

一、SQL 标准与方言

1.1 SQL 标准的演进

SQL-86（SQL-87）：第一版，IBM DB2 主导
SQL-89：minor update
SQL-92（SQL2）：重大升级，加入 JOIN 语法
SQL:1999（SQL3）：触发器、递归、正则
SQL:2003：窗口函数、XML、自动生成 ID
SQL:2006：XML 增强
SQL:2008：INSTEAD OF、TRUNCATE
SQL:2011：时态表
SQL:2016：JSON、行模式识别
SQL:2019：多维数组

观察：
  - SQL 标准 ≠ SQL 实现
  - 每家数据库都"接近标准 + 自有扩展"
  - 实际开发中以厂商文档为准

1.2 各家方言的特点

数据库	方言	风格
Oracle	PL/SQL	过程化、Ada 风格
SQL Server	T-SQL	过程化、C 风格
MySQL	SQL（兼容标准）	极简
PostgreSQL	PL/pgSQL	类 PL/SQL、Oracle 风格

关键观察：
  - Oracle 的 PL/SQL 是最"重"的（包、过程、触发器、对象类型）
  - PG 的 PL/pgSQL 模仿 Oracle（让 Oracle 用户过渡平滑）
  - MySQL 没有强"方言"，更多是 ANSI SQL
  - SQL Server 的 T-SQL 在微软生态独特

二、数据类型对比

2.1 数值类型

用途	Oracle	SQL Server	MySQL	PostgreSQL
整数（小）	NUMBER(7,0)	TINYINT / SMALLINT	TINYINT / SMALLINT	smallint
整数（标准）	NUMBER(10,0)	INT	INT	integer
整数（大）	NUMBER(19,0)	BIGINT	BIGINT	bigint
自定义精度	NUMBER(p,s)	DECIMAL(p,s)	DECIMAL(p,s)	numeric(p,s)
浮点	BINARY_FLOAT/DOUBLE	REAL/FLOAT	FLOAT/DOUBLE	real/double
自增	SEQUENCE + 触发器	IDENTITY	AUTO_INCREMENT	SERIAL/BIGSERIAL

陷阱：
  - Oracle 没有 INT 关键字（其实有别名，但底层都是 NUMBER）
  - Oracle 的 NUMBER(10,0) 占 8~21 字节，比 PG 的 int（4 字节）大
  - MySQL 的 TINYINT(1) 经常被当成 boolean，但存储的还是数字
  - PostgreSQL 的 SERIAL 是 SEQUENCE + DEFAULT 的语法糖

2.2 自增主键

-- Oracle 12c+ 终于有 IDENTITY
CREATE TABLE t (id INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY);

-- 12c 之前：SEQUENCE + 触发器
CREATE SEQUENCE seq_t START WITH 1;
CREATE TABLE t (id INT PRIMARY KEY);
CREATE TRIGGER t_trg BEFORE INSERT ON t
FOR EACH ROW
BEGIN
  SELECT seq_t.NEXTVAL INTO :new.id FROM dual;
END;

-- SQL Server
CREATE TABLE t (id INT IDENTITY(1,1) PRIMARY KEY);

-- MySQL
CREATE TABLE t (id INT AUTO_INCREMENT PRIMARY KEY);

-- PostgreSQL
CREATE TABLE t (id SERIAL PRIMARY KEY);  -- 9.x 经典
-- 或
CREATE TABLE t (id INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY);  -- 10+

2.3 字符串类型

用途	Oracle	SQL Server	MySQL	PostgreSQL
定长	CHAR	CHAR	CHAR	char
变长	VARCHAR2	VARCHAR	VARCHAR	varchar
大文本	CLOB	VARCHAR(MAX) / TEXT	TEXT/LONGTEXT	text
二进制	BLOB	VARBINARY(MAX)	BLOB/LONGBLOB	bytea

坑：
  - Oracle 的 VARCHAR2 vs VARCHAR：官方推荐 VARCHAR2
  - MySQL 的 VARCHAR(255) 之内只用 1 字节存长度，256+ 用 2 字节
  - PostgreSQL 没有 VARCHAR2，统一 varchar
  - SQL Server 的 NVARCHAR 是 UTF-16，VARCHAR 是单字节

2.4 时间类型

用途	Oracle	SQL Server	MySQL	PostgreSQL
日期	DATE（含时间）	DATE	DATE	date
时间	TIMESTAMP	TIME	TIME	time
时间戳	TIMESTAMP	DATETIME2 / DATETIME	DATETIME / TIMESTAMP	timestamp
时区感知	TIMESTAMP WITH TIME ZONE	DATETIMEOFFSET	TIMESTAMP（无）	timestamptz
区间	INTERVAL DAY TO SECOND	——	——	interval

MySQL 的 TIMESTAMP 坑：
  - 范围 1970~2038（4 字节）
  - 自动 UTC 转换
  - 5.6.4+ 支持小数秒
  - DATETIME 不做时区转换，8 字节

2.5 JSON 与高级类型

-- MySQL 5.7+
CREATE TABLE t (data JSON);
SELECT data->'$.name' FROM t;

-- PostgreSQL 9.2+（JSON）/ 9.4+（JSONB）
CREATE TABLE t (data JSONB);
CREATE INDEX idx_data ON t USING GIN(data);
SELECT * FROM t WHERE data @> '{"name":"Alice"}';

-- SQL Server 2016+
CREATE TABLE t (data NVARCHAR(MAX) CHECK (ISJSON(data) > 0));

-- Oracle 12c+
CREATE TABLE t (data CLOB CHECK (data IS JSON));

观察：
  - PG 的 JSONB 最强（二进制存储、GIN 索引、丰富的操作符）
  - MySQL 的 JSON 是文本 + 解析（功能完整但性能不如 JSONB）
  - SQL Server / Oracle 都是"存文本 + 验证"

三、CTE 与窗口函数

3.1 CTE（Common Table Expression）

-- 标准 SQL，四家都支持
WITH active_users AS (
  SELECT id, name FROM users WHERE status = 'active'
),
recent_orders AS (
  SELECT user_id, COUNT(*) AS cnt FROM orders
  WHERE created_at > NOW() - INTERVAL '7 days'
  GROUP BY user_id
)
SELECT u.name, COALESCE(r.cnt, 0) AS order_count
FROM active_users u
LEFT JOIN recent_orders r ON u.id = r.user_id;

3.2 递归 CTE

-- 经典场景：组织架构、菜单树、路径搜索
WITH RECURSIVE org_tree AS (
  -- 基础查询：CEO
  SELECT id, name, parent_id, 1 AS level
  FROM employees
  WHERE id = 1

  UNION ALL

  -- 递归：下属
  SELECT e.id, e.name, e.parent_id, ot.level + 1
  FROM employees e
  JOIN org_tree ot ON e.parent_id = ot.id
)
SELECT level, name FROM org_tree ORDER BY level;

四家支持情况：
  - PostgreSQL：WITH RECURSIVE
  - SQL Server：WITH（不需 RECURSIVE 关键字）
  - Oracle：WITH（11g R2+）
  - MySQL：WITH RECURSIVE（8.0+）

3.3 窗口函数

-- 排名：每个部门薪水前 3
SELECT dept, name, salary,
       ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary DESC) AS rn,
       RANK() OVER (PARTITION BY dept ORDER BY salary DESC) AS rk,
       DENSE_RANK() OVER (PARTITION BY dept ORDER BY salary DESC) AS dense_rk
FROM employees
ORDER BY dept, rn;

-- 累计求和
SELECT date, sales,
       SUM(sales) OVER (ORDER BY date) AS cum_sales
FROM daily_sales;

-- 移动平均
SELECT date, sales,
       AVG(sales) OVER (ORDER BY date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) AS ma7
FROM daily_sales;

-- LAG / LEAD（前后行比较）
SELECT date, sales,
       LAG(sales) OVER (ORDER BY date) AS prev_sales,
       sales - LAG(sales) OVER (ORDER BY date) AS diff
FROM daily_sales;

支持情况：
  - 窗口函数：SQL:2003 标准
  - PostgreSQL 8.4+
  - SQL Server 2005+
  - Oracle 8i+
  - MySQL 8.0+（最晚加入的）

四、查询优化器

4.1 RBO vs CBO

RBO（Rule-Based Optimizer）：
  - 基于规则
  - 比如："有索引就走索引"
  - 不考虑数据分布
  - 简单但僵化
  - Oracle 早期用，现代基本淘汰

CBO（Cost-Based Optimizer）：
  - 基于代价
  - 估算每种执行计划的代价（CPU + I/O）
  - 选最优
  - 需要"统计信息"支撑
  - 现代主流

4.2 CBO 的工作流程

1. 解析 SQL → AST
2. 查询重写（Query Rewrite）
   - 视图展开
   - 谓词下推
   - 子查询展开
   - 常量折叠

3. 计划枚举
   - 单表访问路径（全表扫 / 索引扫 / 索引合并）
   - JOIN 顺序枚举（A JOIN B vs B JOIN A）
   - JOIN 方法（Nested Loop / Hash / Merge）

4. 代价估算
   - 单表代价 = 行数 × 选择率 × 每行代价
   - JOIN 代价 = 左代价 + 右代价 + 连接代价
   - 综合考虑 CPU + I/O

5. 选择最小代价的计划

6. 计划执行

4.3 各家优化器

数据库	优化器	特点
Oracle	CBO	业界标杆，统计信息丰富，Hint 完善
SQL Server	CBO	基于 Cascades 框架
MySQL	CBO（5.7+）	相对简单，Hint 不如 Oracle
PostgreSQL	CBO + GEQO	大表 JOIN 用遗传算法

4.4 PostgreSQL 的 GEQO

问题：多表 JOIN 的顺序枚举复杂度爆炸
  - N 张表 JOIN，组合数 ~ N!
  - 12 表 JOIN：~4.79 亿种顺序

PG 的解法：
  - 表数 ≥ geqo_threshold（默认 12）
  - 切换到 GEQO（Genetic Query Optimization）
  - 用遗传算法找近似最优

代价：
  - 不保证最优
  - 但避免了组合爆炸

五、统计信息

5.1 CBO 的"输入"

CBO 基于统计信息估算：
  - 表行数
  - 列的基数（distinct value 数）
  - 列的最值
  - 数据分布（直方图）
  - 索引高度、叶子数
  - 索引聚簇因子（Cluster Factor）

没有统计信息：
  - CBO 只能猜
  - 经常选错索引
  - 经常全表扫

5.2 直方图

直方图：解决"数据分布不均"

例：status 字段 99% 是 'A'，1% 是 'B'
  WHERE status = 'A' → 99% 行匹配
  WHERE status = 'B' → 1% 行匹配

没直方图：CBO 估算都是 50%（默认假设均匀分布）
有直方图：CBO 知道 'A' 99%，'B' 1%，做精确选择

类型：
  - 频率直方图（Frequency Histogram）
  - 等高直方图（Height-Balanced Histogram）
  - 顶级频率（Top-Frequency）
  - 混合（Hybrid，Oracle 12c+）

5.3 收集统计信息

-- Oracle
EXEC DBMS_STATS.GATHER_TABLE_STATS('SCHEMA', 'TABLE', cascade => TRUE);
EXEC DBMS_STATS.GATHER_SCHEMA_STATS('SCHEMA');

-- SQL Server
UPDATE STATISTICS t;
-- 自动：默认开启（auto_update_statistics）

-- MySQL
ANALYZE TABLE t;
-- 自动：8.0+ 自动采样

-- PostgreSQL
ANALYZE t;
-- 自动：autovacuum 自动分析

关键配置：
  - 目标行数（采样精度）
  - 是否生成直方图
  - 收集频率
  - 收集时机（避开业务高峰）

六、执行计划

6.1 四家的查看方式

-- Oracle
EXPLAIN PLAN FOR SELECT * FROM t WHERE id = 1;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

-- 或更详细：
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(format => 'ALLSTATS LAST'));

-- SQL Server
SET SHOWPLAN_TEXT ON;
GO
SELECT * FROM t WHERE id = 1;
GO
-- 或图形：SSMS → 显示估计的执行计划

-- MySQL
EXPLAIN SELECT * FROM t WHERE id = 1;
EXPLAIN FORMAT=JSON SELECT * FROM t WHERE id = 1;
EXPLAIN ANALYZE SELECT * FROM t WHERE id = 1;  -- 8.0+，实际执行

-- PostgreSQL
EXPLAIN SELECT * FROM t WHERE id = 1;
EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM t WHERE id = 1;

6.2 读懂执行计划

关键字：
  Seq Scan：顺序扫描（全表扫）
  Index Scan：索引扫描（取行）
  Index Only Scan：覆盖索引（不回表）
  Bitmap Heap Scan：先索引位图，再批量取行
  Hash Join：哈希连接（适合大表）
  Nested Loop：嵌套循环（适合小表）
  Merge Join：归并连接（已有序）
  HashAggregate：哈希聚合
  Sort：排序

阅读顺序：
  - 从最里层（缩进最深）开始读
  - 自下而上组合
  - 关注 rows、cost、actual time

判断：
  - "rows 估算 = 实际行数" → 统计信息准确
  - "rows 估算 << 实际行数" → 统计信息过时
  - "Seq Scan 在大表" → 缺索引
  - "Hash Join 内存爆炸" → 内存配置低

6.3 EXPLAIN ANALYZE 的威力

-- PostgreSQL
EXPLAIN (ANALYZE, BUFFERS, VERBOSE)
SELECT u.name, COUNT(*) AS cnt
FROM users u JOIN orders o ON u.id = o.user_id
WHERE u.created_at > '2026-01-01'
GROUP BY u.name
ORDER BY cnt DESC
LIMIT 10;

-- 输出包含：
  - 估算行数 vs 实际行数
  - 估算代价 vs 实际时间
  - 缓冲区命中（shared hits vs read）
  - 内存使用（Hash Memory）
  - IO 时间

七、常见坑与优化

7.1 隐式类型转换

-- 经典坑：phone 是 VARCHAR，传 INT
SELECT * FROM users WHERE phone = 13800000000;

MySQL：自动转换 → CAST(phone AS INT) → 不走索引
PG：报错（更严格，避免错误）
Oracle：可能转换 → 索引失效

→ 解决：传字符串 '13800000000'

7.2 参数嗅探（Parameter Sniffing）

SQL Server 的经典问题：

  CREATE PROCEDURE get_user(@age INT) AS
    SELECT * FROM users WHERE age = @age;
  GO

  -- 第一次执行：@age = 18
  -- CBO 看 'age=18' 选择率高 → 走索引
  -- 缓存这个计划

  -- 第二次执行：@age = 30
  -- 实际选择率低，应该全表扫
  -- 但用了缓存的"走索引"计划 → 慢

解决：
  - OPTIMIZE FOR UNKNOWN：用平均选择率
  - OPTION (RECOMPILE)：每次重新编译
  - 局部变量绕过嗅探

7.3 绑定变量 vs 字面量

Oracle 经典问题：共享池污染

  不用绑定变量：
    SELECT * FROM t WHERE id = 1;
    SELECT * FROM t WHERE id = 2;
    SELECT * FROM t WHERE id = 3;
    → 每条都是不同 SQL → 都要解析 → 共享池爆炸

  用绑定变量：
    SELECT * FROM t WHERE id = :1;
    → 一次解析多次复用 → 高效

MySQL：
  - 没有"共享池"概念
  - 但 prepared statement 也有类似优化

7.4 谓词下推

-- 优化前：先 JOIN 再过滤
SELECT * FROM big_table b JOIN small_table s ON b.id = s.id
WHERE s.status = 'active';

-- 优化后（CBO 自动）：先过滤 small_table，再 JOIN
SELECT * FROM big_table b JOIN (
  SELECT * FROM small_table WHERE status = 'active'
) s ON b.id = s.id;

-- 四家 CBO 都会自动做谓词下推
-- 但视图 / 子查询嵌套深时可能失败 → 手动改写

7.5 N+1 查询问题

ORM 常见问题：
  users = User.objects.all()[:100]    # 1 次查询
  for u in users:
      print(u.profile.bio)            # 每次循环都查一次

  → 100 个用户做了 101 次查询（N+1）

解决：
  - ORM 的 prefetch_related / eager loading
  - 手写 JOIN
  - DataLoader 模式

八、Hint（提示）

8.1 强制 CBO 选某个计划

-- Oracle
SELECT /*+ INDEX(t idx_name) */ * FROM t WHERE name = 'Alice';
SELECT /*+ FULL(t) */ * FROM t WHERE id = 1;
SELECT /*+ LEADING(t1 t2) USE_HASH(t2) */ ...
FROM t1 JOIN t2 ON ...;

-- MySQL 8.0+ 也支持
SELECT /*+ NO_RANGE_OPTIMIZATION(t PRIMARY) */ * FROM t WHERE id < 100;
SELECT /*+ JOIN_ORDER(a, b, c) */ ...

-- PostgreSQL：不支持 Hint（设计哲学不同）
-- 替代：调整统计信息、SET enable_xxx = off、改写 SQL

PG 反对 Hint 的哲学：
  - Hint 让 SQL 变得"非声明式"
  - 数据变化后 Hint 仍然生效 → 性能反而变差
  - 应该让 CBO 不断改进，而不是手工指定

8.2 Hint 何时用

适用场景：
  - CBO 选错索引（统计信息不足）
  - 临时强制某种 JOIN 方法
  - 临时强制某种顺序

不适用：
  - 长期解决方案（应该修统计信息）
  - 每条 SQL 都加（说明统计信息严重缺失）

九、查询重写技巧

9.1 IN vs EXISTS

-- 经典问题：IN vs EXISTS 谁快？

-- 没有定论，取决于：
  - 子查询大小
  - 外查询大小
  - CBO 实现

-- 现代优化器都能互相转换，效果相同
-- 经验：小表用 IN，大表用 EXISTS（CBO 时代无所谓了）

9.2 NOT IN vs NOT EXISTS

-- NOT IN 的 NULL 陷阱
SELECT * FROM a WHERE id NOT IN (SELECT a_id FROM b);
-- 如果 b.a_id 有 NULL → 整个查询返回空！

-- NOT EXISTS 更安全
SELECT * FROM a WHERE NOT EXISTS (SELECT 1 FROM b WHERE b.a_id = a.id);

-- 解决方案：IS NOT NULL
SELECT * FROM a WHERE id NOT IN (
  SELECT a_id FROM b WHERE a_id IS NOT NULL
);

9.3 避免 SELECT *

不要 SELECT *：
  - 占用带宽（无用列也传输）
  - 无法用覆盖索引
  - 表结构变化时可能出 bug
  - 阻断某些视图优化

例外：
  - 临时调试
  - COUNT(*)（COUNT(1) 没有差异）

十、小结

本文学习了 SQL 方言与查询优化器：

SQL 标准的演进与各家方言差异
数据类型对比（数值 / 字符串 / 时间 / JSON）
CTE 与窗口函数（递归、排名、累计、LAG/LEAD）
RBO vs CBO 的工作原理
统计信息（行数、基数、直方图）的重要性
执行计划的查看与阅读
常见坑：隐式转换、参数嗅探、绑定变量、N+1
Hint 使用与限制
查询重写技巧

记住三句话：
  1. 90% 的"数据库慢"问题，根因是统计信息过时
  2. EXPLAIN ANALYZE（或等效命令）是性能调优的第一工具
  3. 优化 SQL 不是优化"语法"，是优化"执行计划"

下一篇是系列收官：跳出关系数据库，俯瞰整个数据存储生态——OLTP / OLAP / HTAP / 数仓 / Lakehouse / NoSQL 一图看懂。

数据库系列（八）：复制与高可用 — 主从、半同步、MGR、AlwaysOn、ADG

Sun, 14 Jun 2026 22:00:00 +0800

写在前面

承接前一篇日志，本文进入"复制与高可用"——单机数据库解决不了的问题。

本文要回答：

主从怎么同步？半同步和异步有什么区别？为什么 MySQL 有 MGR、SQL Server 有 AlwaysOn、Oracle 有 RAC、PG 有流复制？脑裂怎么防？Paxos 和 Raft 是什么？

一、为什么需要复制

1.1 单机的瓶颈

单机数据库的天花板：
  - 容量：单机磁盘上限（TB 级）
  - 性能：单机 CPU/内存（万级 QPS）
  - 可用性：单点故障
  - 地理分布：跨地域延迟

复制解决：
  - 高可用：主库挂了切从库
  - 读扩展：读分摊到多个从库
  - 备份：从库做统计/备份，不影响主库
  - 跨地域：在多地部署从库

1.2 复制的基本问题

1. 复制什么？
   - 物理日志（Redo/WAL）
   - 逻辑日志（Binlog/逻辑复制）

2. 同步还是异步？
   - 异步：主写完就返回，不等从
   - 同步：主等所有从确认才返回
   - 半同步：主等至少一个从确认

3. 谁来选主？
   - 人工指定（传统主从）
   - 自动选主（MGR / AlwaysON / Patroni）

4. 怎么处理脑裂？
   - Quorum（多数派）
   - Fencing（隔离故障主）
   - 见证服务器

二、物理复制 vs 逻辑复制

2.1 物理复制

复制"字节流"——主库 Redo/WAL 直接传给从库

主库                         从库
  Redo Log ─────────────────→ 应用到本地数据页

特点：
  ✅ 速度快（字节流直接应用）
  ✅ 一致性强（页级精确）
  ❌ 从库必须同版本、同平台
  ❌ 不能跨大版本
  ❌ 不能选择性复制

2.2 逻辑复制

复制"逻辑变更"——主库解析出"哪行被改了"，传给从库

主库                         从库
  Binlog / 逻辑日志 ────────→ 解析为 INSERT/UPDATE/DELETE

特点：
  ✅ 跨版本（甚至跨数据库引擎）
  ✅ 可选择性复制（按表 / 库）
  ✅ 异构系统（OLTP→OLAP）
  ❌ 性能略低于物理复制
  ❌ DDL 不会自动复制（PG）
  ❌ 一致性不如物理复制

2.3 四家选择

数据库	默认复制方式
Oracle	物理（Data Guard）+ 逻辑（GoldenGate）
SQL Server	物理（AlwaysOn）
MySQL	逻辑（Binlog，传统主从）
PostgreSQL	物理（流复制）+ 逻辑（10+）

三、MySQL 复制体系

3.1 传统异步复制

架构：
  Master（Binlog）──────→ IO Thread（Slave）──→ Relay Log
                                                  ↓
                                            SQL Thread（Slave）
                                                  ↓
                                              应用到数据

特点：
  - 主库写完 Binlog 即返回，不等从库确认
  - 从库异步拉取 Binlog
  - 可能丢数据（主库崩溃时未同步的事务）

3.2 半同步复制（Semi-Sync）

5.5+ 引入，5.7+ 增强

工作流程：
  1. 主库写 Binlog
  2. 主库 COMMIT 时，至少一个从库 ACK
  3. 主库收到 ACK 后才返回客户端成功

特点：
  - 主库挂了不丢已 ACK 的事务
  - 至少一个从库有数据
  - 性能比异步慢（多等一个网络往返）

-- 主库
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 = 1000;  -- ms，超时降级为异步

-- 从库
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
SET GLOBAL rpl_semi_sync_slave_enabled = 1;

3.3 组复制（MGR）

MySQL 8.0+ 提供的高可用方案
基于 Paxos 协议

架构：
  Primary ─────┐
               │
  Secondary ───┤  组（Group）
               │
  Secondary ───┘
  所有成员通过 Paxos 同步事务

特点：
  - 多主复制（可以多 Primary 写入）
  - 自动故障检测和选主
  - 强一致性（事务提交需多数派确认）
  - 至少 3 节点（容忍 1 节点失败）

要求：
  - 必须用 GTID
  - 表必须有主键
  - 默认 RR 隔离级别
  - 不支持外键、Savepoint 跨节点

# my.cnf 示例
[mysqld]
gtid_mode = ON
enforce_gtid_consistency = ON
plugin_load_add = 'group_replication.so'
group_replication_group_name = "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
group_replication_local_address = "node1:33061"
group_replication_group_seeds = "node1:33061,node2:33061,node3:33061"
transaction_write_set_extraction = XXHASH64

3.4 三种方案对比

方案	一致性	性能	自动故障转移	部署复杂度
异步复制	弱	高	❌	简单
半同步复制	中	中	❌	中
MGR	强	中	✅	复杂

选型建议：
  - 互联网 OLTP（容忍少量数据丢失）：异步 + MHA
  - 重要业务（要数据安全）：半同步 + Orchestrator
  - 关键业务（要求强一致）：MGR（或上 TiDB）

四、PostgreSQL 复制

4.1 流复制（Streaming Replication）

物理复制，基于 WAL

架构：
  Primary ────WAL stream────→ Standby（连续应用）

工作流程：
  1. Primary 写 WAL
  2. WAL Sender 进程推送给 Standby
  3. Standby 的 WAL Receiver 接收
  4. Standby 进程应用 WAL

特点：
  - 物理字节流
  - 支持同步 / 异步
  - 支持"级联复制"（Standby 也能转发）
  - Standby 默认只读（Hot Standby）

# postgresql.conf
wal_level = replica              # 或 logical
synchronous_commit = on
synchronous_standby_names = '*'  # 同步复制（指定 Standby 名）

# Standby recovery.conf / postgresql.auto.conf
primary_conninfo = 'host=primary port=5432'
hot_standby = on                 # 允许在恢复中查询

4.2 同步复制

PG 同步复制级别（synchronous_commit）：
  remote_apply  = 等从库应用完事务（最严格）
  remote_flush  = 等从库 fsync WAL
  remote_write  = 等从库写 OS Cache
  local         = 只等本地 fsync
  off           = 不等任何东西

4.3 逻辑复制（10+）

基于"Publication / Subscription"模型

发布者（主库）：
  CREATE PUBLICATION pub_orders FOR TABLE orders;
  -- 只发布 orders 表

订阅者（从库）：
  CREATE SUBSCRIPTION sub_orders
  CONNECTION 'host=primary'
  PUBLICATION pub_orders;

逻辑复制用途：
  - 选择性复制（只复制部分表）
  - 异构系统（PG → Doris / ClickHouse）
  - 滚动升级（旧版 → 新版）
  - 多活双向（Bidirectional，复杂）

限制：
  - 不复制 DDL（要手动同步）
  - 不复制大对象
  - 没有 schema 一致性保证

4.4 PG 高可用方案

PG 本身不提供"自动故障转移"，需要外部工具：

  - Patroni（Zalando 开源，最流行）
    基于 etcd / ZooKeeper / Consul
    自动选主 + 自动重配

  - repmgr（2ndQuadrant 开源）
    基于 PG 流复制
    简单但功能有限

  - pg_auto_failover（Citus 开源）
    基于见证节点（monitor）
    部署简单

  - Stolon（基于 etcd）
    类似 Patroni

五、SQL Server AlwaysOn

5.1 两种 AlwaysOn

AlwaysOn Availability Group（AG）：
  - 应用层高可用
  - 数据库级故障转移
  - 多个副本（1 主 + 8 副）
  - 副本可读

AlwaysOn Failover Cluster Instance（FCI）：
  - 实例层高可用
  - 共享存储（SAN）
  - 节点级故障转移
  - 经典 Windows 集群方案

5.2 AG 工作流程

架构：
  Primary Replica ──┬──→ Secondary Replica 1（同步）
                    │
                    └──→ Secondary Replica 2（异步）

特点：
  - 基于 SQL Server Network Name（AD 域）
  - Listener：一个虚拟 IP，应用连接它
  - 故障自动转移（次要副本升级为 Primary）
  - 副本可读（默认 NO，配置后可读）

可用性模式：
  SYNCHRONOUS_COMMIT：等副本同步（强一致）
  ASYNCHRONOUS_COMMIT：不等副本（性能优先）

-- 创建 AG（T-SQL）
CREATE AVAILABILITY GROUP MyAG
WITH (
    AUTOMATED_BACKUP_PREFERENCE = PRIMARY,
    DB_FAILOVER = ON,
    DTC_SUPPORT = NONE
)
FOR DATABASE MyDB
REPLICA ON
  'Node1' WITH (
    ENDPOINT_URL = 'TCP://node1:5022',
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
    FAILOVER_MODE = AUTOMATIC,
    SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)
  ),
  'Node2' WITH (
    ENDPOINT_URL = 'TCP://node2:5022',
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
    FAILOVER_MODE = AUTOMATIC,
    SECONDARY_ROLE(ALLOW_CONNECTIONS = READ_ONLY)
  );

六、Oracle 高可用

6.1 Active Data Guard（ADG）

物理 Standby，可以同时读

架构：
  Primary ──Redo Log Stream──→ Standby（Active）
                                 ↓
                              开放只读查询

特点：
  - 物理复制（Redo 流）
  - Standby 应用 Redo 时仍可读（Real Apply Time）
  - Fast-Start Failover（FSFO）：自动故障转移
  - 可以"读时备份"，主库无压力

6.2 Oracle RAC（Real Application Cluster）

多节点共享存储集群

架构：
  ┌──────┐  ┌──────┐  ┌──────┐
  │Node 1│  │Node 2│  │Node 3│   ← 多实例
  └──┬───┘  └──┬───┘  └──┬───┘
     │         │         │
     └─────────┼─────────┘
               │
        共享存储（ASM / SAN）

特点：
  - 共享存储（所有节点访问同一数据）
  - Cache Fusion：节点间内存共享
  - 任何节点都能写
  - 单节点崩溃不影响业务
  - 商业版独有 + 价格昂贵

适用：
  - 关键业务（金融核心）
  - 高并发 + 不能停服
  - 预算充足

6.3 Oracle Sharding

12.2+ 引入的分片方案
  - 按列分片（hash/range/list）
  - 每个分片独立数据库
  - 应用通过 Sharding Key 路由
  - 类似 MySQL 分库分表

七、共识协议

7.1 为什么需要共识

分布式系统的根本问题：
  - 多个节点如何对一个值达成一致？
  - 节点可能崩溃、网络可能延迟、消息可能丢

共识协议（Consensus Algorithm）：
  - Paxos（1989 Lamport）
  - Raft（2014 Ongaro）
  - ZAB（ZooKeeper 用）
  - Gossip（Cassandra 用，弱一致）

7.2 Raft 简化理解

Raft 把共识拆成三部分：
  1. Leader 选举
  2. 日志复制
  3. 安全性

角色：
  Leader：唯一写入入口
  Follower：被动接受
  Candidate：候选人（选举中）

选举：
  - Leader 心跳超时 → Follower 成为 Candidate
  - Candidate 拉票 → 获多数票 → 成为 Leader
  - 一个 Term 最多一个 Leader

日志复制：
  1. 客户端请求 → Leader
  2. Leader 写本地日志，向 Follower 复制
  3. 多数派 ACK → COMMIT
  4. 返回客户端

特点：
  - 多数派（Majority）原则
  - 容忍 (N-1)/2 节点失败
  - 3 节点容忍 1 失败，5 节点容忍 2 失败

7.3 数据库中的应用

数据库	共识协议
MySQL MGR	Paxos 变种（Mencius / EPaxos）
CockroachDB	Raft
TiDB / TiKV	Raft（Multi-Raft）
YugabyteDB	Raft
Spanner	Paxos

八、脑裂与防护

8.1 什么是脑裂

场景：网络分区
  - 主库和多数派失去联系
  - 多数派选了新主
  - 旧主以为自己是主，继续接受写
  - → 两个主同时写 → 数据冲突

危险：
  - 数据不一致（双主写入）
  - 业务错乱
  - 恢复困难

8.2 防护机制

1. Quorum（多数派）
   - 只有获得多数派支持才能成为主
   - 网络分区时少数派自动降级

2. Fencing（隔离）
   - STONITH（Shoot The Other Node In The Head）
   - 物理断电旧主
   - PG 的"wal_loghints" + 多数派

3. 见证服务器（Witness）
   - 独立第三方仲裁
   - SQL Server AlwaysOn 见证
   - Patroni 的 DCS（etcd）

4. Split-Brain Avoidance
   - 多个心跳路径
   - 多数派 + 时间窗口

8.3 各家的脑裂处理

MySQL MGR：多数派
  - 失去多数派的分区自动进入"只读"
  - group_replication_unreachable_majority_timeout

PostgreSQL Patroni：DCS（etcd）+ 多数派
  - 主库失去 DCS 连接 → 自动降级为 Standby
  - 类似"租约"（Lease）

SQL Server AlwaysOn：Windows Failover Cluster 仲裁
  - Node Majority / Node + Disk Witness / Node + File Share Witness

Oracle RAC：CSS（Cluster Synchronization Service）
  - 节点驱逐（Node Eviction）
  - 网络心跳 + 磁盘心跳

九、读写分离

9.1 架构模式

模式 1：应用层路由
  Application ──┬──→ Primary（读写）
                │
                └──→ Standby（只读）

模式 2：代理层路由
  Application ──→ Proxy（ProxySQL / HAProxy）
                    ↓
                ┌──┴──┐
              Primary  Standby

模式 3：驱动层路由
  JDBC URL 配多节点
  Connector/J 自动路由

9.2 一致性问题

"写后读"问题：
  T1: 用户写评论 → 主库
  T2: 用户刷新 → 读从库（延迟）→ 看不到自己的评论
  → 用户体验差

解决方案：
  1. 关键路径强制走主库（用户自己的数据）
  2. 会话粘滞（写后 5 秒内读主库）
  3. 半同步复制降低延迟
  4. 业务设计容忍延迟

9.3 主从延迟监控

-- MySQL
SHOW SLAVE STATUS\G
-- 关注：Seconds_Behind_Master

-- PostgreSQL
SELECT * FROM pg_stat_replication;
-- 关注：write_lag / flush_lag / replay_lag

-- SQL Server
SELECT * FROM sys.dm_hadr_database_replica_states;
-- 关注：log_send_queue_size / redone_queue_size

-- Oracle ADG
SELECT * FROM v$dataguard_stats;
-- 关注：apply lag

十、小结

本文学习了复制与高可用：

复制动机：高可用、读扩展、备份、跨地域
物理复制 vs 逻辑复制
MySQL 三套方案：异步 / 半同步 / MGR
PostgreSQL 流复制 + 逻辑复制 + 外部高可用工具
SQL Server AlwaysOn AG / FCI
Oracle ADG + RAC + Sharding
Raft / Paxos 共识协议
脑裂防护（Quorum / Fencing / 见证服务器）
读写分离与一致性方案

记住三句话：
  1. 强一致 = 性能代价（同步复制慢）
  2. 多数派共识是分布式数据库的核心（MGR / TiDB / CockroachDB）
  3. 高可用 = 复制 + 自动故障转移 + 脑裂防护，三者缺一不可

下一篇进入 SQL 方言与查询优化器：为什么同样的 SQL 在 PG 比 MySQL 快 10 倍？统计信息、执行计划、CBO 的差异。

数据库系列（七）：日志与崩溃恢复 — ARIES、WAL、Checkpoint

Sun, 14 Jun 2026 21:00:00 +0800

写在前面

承接前几篇，本文聚焦"日志与崩溃恢复"——这是数据库 D（持久性）的实现核心。

本文要回答：

Redo Log、Undo Log、Binlog、WAL、Archive Log、Transaction Log——这么多日志都是干嘛的？数据库崩溃后是怎么自动恢复的？为什么 Oracle 重启很快但 MySQL 重启有时很慢？

一、ARIES 协议

1.1 数据库恢复的理论基础

ARIES（Algorithm for Recovery and Isolation Exploiting Semantics）是 1992 年 IBM 提出的恢复算法，所有现代关系数据库都基于它（变体）。

1.2 三阶段恢复

ARIES 三阶段：
  1. Analysis（分析）：扫描日志，重建事务表 + 脏页表
  2. Redo（重做）：重放所有"已提交但未刷盘"的修改
  3. Undo（回滚）：回滚所有"未提交但已写盘"的修改

关键概念：
  - LSN（Log Sequence Number）：日志序号，全局递增
  - WAL 原则：数据页刷盘前，对应日志必须先刷盘

1.3 完整流程示例

时间线：
  T1: BEGIN
  T1: UPDATE balance SET v = 100 WHERE id = 1;
      - 写 Undo Log: id=1, old_v = 50
      - 写 Redo Log: id=1, new_v = 100
  T2: BEGIN
  T2: UPDATE balance SET v = 200 WHERE id = 2;
      - 写 Undo Log: id=2, old_v = 80
      - 写 Redo Log: id=2, new_v = 200
  T1: COMMIT
      - 写 COMMIT Log
      - fsync Redo Log
  [崩溃]

重启后：
  Analysis：
    - T1 已提交（看到 COMMIT）
    - T2 未提交（没有 COMMIT）

  Redo（从某个 LSN 开始）：
    - 重做 T1: id=1 改成 100
    - 重做 T2: id=2 改成 200

  Undo：
    - 回滚 T2: 用 Undo Log 改回 id=2 = 80

  最终：
    - id=1: 100（T1 已提交）
    - id=2: 80（T2 已回滚）

二、Redo Log vs Undo Log

2.1 物理日志 vs 逻辑日志

物理日志（Physical Log）：
  - 记录"页 X 偏移 Y 改成值 Z"
  - Redo Log 都是物理日志（或物理到逻辑混合）
  - 重放时精确还原页面

逻辑日志（Logical Log）：
  - 记录"事务 T 在表 t 改了什么"（行级、SQL 级）
  - Undo Log 多为逻辑日志
  - Binlog 是逻辑日志

为什么 Redo 必须物理？
  - 重放时不能假设页处于某种状态
  - 物理日志幂等（重复执行结果一致）

2.2 Redo Log 作用

1. 崩溃恢复：重做未刷盘的已提交事务
2. 加速 COMMIT：顺序写 Redo 比"刷数据页"快得多
3. 支持 PITR（Point-in-Time Recovery，配合归档日志）

特点：
  - 物理日志
  - 顺序追加（部分循环覆盖）
  - 大小固定（一组文件）

2.3 Undo Log 作用

1. 事务回滚：失败时撤销修改
2. MVCC：保留旧版本供并发读
3. 崩溃恢复：回滚未提交事务

特点：
  - 逻辑日志（"改回什么值"）
  - 通常顺序追加
  - 大小动态（不固定）

三、四大数据库的日志体系

3.1 Oracle

日志类型：
  - Redo Log（在线 + 归档）
  - Undo Segment（独立表空间）

文件结构：
  online redo log：3+ 组，每组 1+ 文件，循环写
    redo01.log → redo02.log → redo03.log → 覆盖 redo01.log ...

  archive log：归档模式（ARCHIVELOG）下，被覆盖前复制到归档位置

关键参数：
  LOG_BUFFER：Redo Log Buffer 大小
  LOG_ARCHIVE_DEST_n：归档目的地
  FAST_START_MTTR_TARGET：崩溃恢复目标时间

3.2 SQL Server

日志类型：
  - Transaction Log（.ldf 文件）
  - 同时承担 Redo 和 Undo（没有独立 Undo Log）

特点：
  - 单一日志（不像其他三家分开）
  - 通过版本号在日志中区分 Redo/Undo 部分
  - 数据库每个都有独立的 .ldf

工作流程：
  1. 修改数据 → 写 Log Buffer
  2. COMMIT → flush Log Buffer 到 .ldf
  3. 后台 Checkpoint 刷数据页
  4. 崩溃恢复：扫 .ldf 重做 / 回滚

关键参数：
  recovery interval：目标恢复时间
  target_recovery_time：每库目标恢复时间（秒）

3.3 MySQL InnoDB

日志类型：
  - Redo Log（ib_redo*，8.0+ 改名）
  - Undo Log（undo tablespace）
  - Binlog（Server 层，独立于引擎）

为什么要三套？
  - Redo + Undo：引擎内部崩溃恢复
  - Binlog：主从复制 + 备份
  - 内部 XA 协调 Redo 和 Binlog

工作流程（详见第 4 篇）：
  1. 改 Buffer Pool
  2. 写 Undo Log
  3. PREPARE Redo Log（fsync）
  4. 写 Binlog（fsync）
  5. COMMIT Redo Log（fsync）

关键参数：
  innodb_flush_log_at_trx_commit：Redo 刷盘策略（0/1/2）
  sync_binlog：Binlog 刷盘策略（0/1/N）
  innodb_log_file_size：单个 Redo Log 文件大小
  innodb_log_files_in_group：Redo Log 文件数

3.4 PostgreSQL

日志类型：
  - WAL（Write-Ahead Log，pg_wal/ 目录）
  - 没有 Undo Log（多版本直接存在 Heap）

特点：
  - 单一日志（WAL）
  - 物理日志为主（8.0+ 部分逻辑）
  - 8.0+ 支持 logical replication（基于逻辑日志）

工作流程：
  1. 改 Buffer（标记脏页）
  2. 写 WAL Buffer
  3. COMMIT → fsync WAL Buffer
  4. 后台 Checkpoint 刷脏页

关键参数：
  wal_level：minimal / replica / logical
  synchronous_commit：on / off / remote_write / remote_flush
  max_wal_size：WAL 大小上限（自动 checkpoint）
  wal_keep_size：为流复制保留的 WAL 大小

3.5 横向对比

维度	Oracle	SQL Server	MySQL	PostgreSQL
Redo	Redo Log	Transaction Log	Redo Log	WAL
Undo	Undo Segment	（在 .ldf 中）	Undo Log	Heap 内（旧 tuple）
归档	Archive Log	Log Backup	Binlog	WAL Archive
复制	Redo Stream	Transaction Log	Binlog	WAL Stream

四、Checkpoint

4.1 为什么需要 Checkpoint

没有 Checkpoint 的问题：
  - 崩溃恢复时，需要从头扫描所有 Redo Log
  - Log 文件越来越大 → 恢复时间越来越长
  - 不可能接受

Checkpoint 的作用：
  - 定期把所有脏页刷盘
  - 在 Redo Log 中记录"Checkpoint LSN"
  - 崩溃恢复时从 Checkpoint LSN 开始扫
  - 缩短恢复时间（MTTR）

4.2 工作机制

Checkpoint 流程：
  1. 记录当前 Redo Log LSN（记为 C）
  2. 把 Buffer Pool 中所有"LSN ≤ C"的脏页刷盘
  3. 在 Redo Log 中写入 Checkpoint 记录
  4. 更新控制文件中的"最新 Checkpoint LSN"

崩溃恢复：
  - 从 Checkpoint LSN 开始扫 Redo Log
  - 之前的数据已经持久化，不需要重做

4.3 各家的 Checkpoint

数据库	触发机制	关键参数
Oracle	基于时间（MTTR）	FAST_START_MTTR_TARGET、FAST_START_IO_TARGET
SQL Server	基于时间 + LSN	recovery interval、indirect checkpoint
MySQL InnoDB	基于 LSN 上限	innodb_max_dirty_pages_pct、innodb_io_capacity
PostgreSQL	基于 WAL 大小 + 时间	max_wal_size、checkpoint_timeout

-- MySQL：控制 Checkpoint 速度
SET GLOBAL innodb_max_dirty_pages_pct = 75;
SET GLOBAL innodb_io_capacity = 2000;

-- PostgreSQL：调整 Checkpoint 频率
ALTER SYSTEM SET max_wal_size = '4GB';
ALTER SYSTEM SET checkpoint_timeout = '15min';

4.4 Fuzzy Checkpoint

现代数据库都用"Fuzzy Checkpoint"：
  - 不停服
  - 不冻结写操作
  - 后台慢慢刷脏页
  - 用户无感

代价：
  - 需要"两阶段 Checkpoint"（开始/结束 LSN）
  - 恢复时小范围可能重复 Redo（可接受）

五、崩溃恢复全过程

5.1 通用流程

1. 读取控制文件，找到最新 Checkpoint LSN
2. 从该 LSN 开始扫 Redo Log
   - 重建事务表（哪些事务 BEGIN / COMMIT / ROLLBACK）
   - 重建脏页表（哪些页被修改过）
3. Redo 阶段
   - 重放 Checkpoint 之后的所有修改
   - 已提交 + 未提交都重做（保证页面状态）
4. Undo 阶段
   - 扫描未提交事务的 Undo Log
   - 回滚这些事务的修改
5. 数据库进入正常状态，开始接受连接

5.2 影响恢复时间的因素

1. Checkpoint LSN 到崩溃时刻的距离
   - 距离越远，Redo 量越大
   - 调小 Checkpoint 间隔可以缩短恢复时间

2. 未提交事务的数量
   - 长事务多 → Undo 量大
   - 长事务是恢复性能杀手

3. 磁盘随机 I/O 性能
   - 恢复涉及大量随机读（读脏页）
   - SSD 比 HDD 恢复快 10~100 倍

4. 并行恢复能力
   - Oracle：多线程并行 Redo / Undo
   - PG：单线程，慢
   - MySQL：InnoDB 8.0+ 部分并行

5.3 实战：恢复时间监控

-- Oracle：看上次恢复的预估时间
SELECT estimated_mttr FROM v$instance_recovery;

-- MySQL：InnoDB 恢复日志
-- 在 mysqld 启动日志中查看：
-- "InnoDB: Doing recovery: scanned X log"
-- "InnoDB: Database was not shutdown normally"

-- PostgreSQL：在启动日志中
-- "starting archive recovery"
-- "redo starts at X"
-- "redo done at Y"
-- "recovery stopping after commit timestamp Z"

六、刷盘策略与"双一"标准

6.1 刷盘时机

每次写文件系统的"写"操作其实分两步：
  1. 写 OS Page Cache（write()）
  2. 刷到磁盘（fsync()）

数据库的"刷盘"通常指 fsync()。

6.2 MySQL 的双一标准

innodb_flush_log_at_trx_commit = 1
sync_binlog = 1

含义：
  - innodb_flush_log_at_trx_commit = 1
    每次 COMMIT 都 fsync Redo Log → D（持久性）保证
  - sync_binlog = 1
    每次事务都 fsync Binlog → 复制一致性保证

为什么叫"双一"？
  - 两个参数都 = 1
  - 金融场景必须
  - 性能代价：每事务多 1~2 次 fsync

6.3 不同级别权衡

innodb_flush_log_at_trx_commit:
  0 = 每秒 fsync（崩溃丢最多 1 秒事务）→ 性能好
  1 = 每次 fsync（永不丢）→ 默认、最安全
  2 = 每次 COMMIT 写 OS Cache，每秒 fsync（OS 崩溃丢，DB 崩溃不丢）

sync_binlog:
  0 = 由 OS 决定刷盘时机
  1 = 每次事务都 fsync → 默认（5.7+）
  N = 每 N 个事务 fsync 一次

6.4 PostgreSQL 的对应

synchronous_commit = on    -- 等于 innodb_flush_log_at_trx_commit = 1
synchronous_commit = off   -- 等于 0
synchronous_commit = local -- 类似 1（单机场景）

wal_sync_method = fsync    -- 刷盘方法
wal_writer_delay = 200ms   -- WAL Writer 后台刷盘间隔

七、Binlog 详解

7.1 Binlog 是什么

MySQL Server 层的逻辑日志
  - 记录"所有已提交事务的修改"
  - 用于主从复制、PITR、CDC（变更数据捕获）

Binlog 格式：
  - STATEMENT：记录 SQL 语句（小，但有些函数 / NOW() 不安全）
  - ROW：记录每行的修改（大，但安全）  ← 推荐
  - MIXED：自动选择

7.2 Binlog vs Redo Log

维度	Redo Log	Binlog
层级	引擎层（InnoDB）	Server 层
内容	物理日志（页/偏移）	逻辑日志（行变更）
写入	循环覆盖	追加写，文件按序号
用途	崩溃恢复	复制、备份、CDC
大小	固定（几个 G）	一直增长

7.3 为什么需要内部 XA

场景：Redo Log 已写但 Binlog 还没写时崩溃
  - 重启后：InnoDB 看到 PREPARE 状态，回滚事务
  - 但如果该事务的 Redo 已经被从库消费（不可能，因为还没 COMMIT）...

实际场景：Redo 写完、Binlog 写了一半时崩溃
  - 重启后：扫 Redo 找到 PREPARE 事务
  - 检查 Binlog 是否完整：
    * 完整 → 重做（保证从库能消费）
    * 不完整 → 回滚（保证与从库一致）

→ 内部 XA 协议保证 Redo + Binlog 的一致性

八、归档与 PITR

8.1 为什么需要归档

Redo Log / WAL 是循环写的，会被覆盖
  - 在线 Redo 容量有限（通常几个 G）
  - 几小时前的修改可能已经丢失

归档（Archive）：
  - 把"将要被覆盖"的 Redo / WAL 复制到归档目录
  - 归档文件永久保存（直到备份策略清理）
  - 用于：
    * 物理备份恢复到任意时间点（PITR）
    * 增量备份基础
    * 流复制从库延迟追赶

8.2 各家的归档

Oracle：Archive Log
  - 数据库必须开 ARCHIVELOG 模式
  - 后台进程 ARCn 自动归档
  - RMAN 备份 / 恢复工具

SQL Server：Transaction Log Backup
  - 数据库必须 FULL 或 BULK_LOGGED 恢复模式
  - 主动执行 BACKUP LOG 命令

MySQL：Binlog（自动归档）
  - 默认 binlog 一直保留
  - binlog_expire_logs_seconds 控制保留时间

PostgreSQL：WAL Archive
  - archive_mode = on
  - archive_command = 'cp %p /backup/%f'
  - 11+ 支持 replication slot + 物理备份

8.3 PITR（Point-in-Time Recovery）

场景：今天 14:00 误删了重要表，需要恢复到 13:59:59

流程：
  1. 用一周前的全量备份恢复（base restore）
  2. 应用归档日志，重放到目标时间点
  3. 用 RESETLOGS / 类似命令打开数据库

各家命令：
  Oracle：RMAN RECOVER DATABASE UNTIL TIME "TO_DATE('2026-06-15 13:59:59')"
  SQL Server：RESTORE LOG ... WITH STOPAT='2026-06-15 13:59:59'
  MySQL：mysqlbinlog --stop-datetime='2026-06-15 13:59:59' binlog.* | mysql
  PostgreSQL：recovery_target_time = '2026-06-15 13:59:59'

九、小结

本文学习了日志与崩溃恢复：

ARIES 协议：Analysis → Redo → Undo 三阶段
物理日志（Redo）vs 逻辑日志（Undo/Binlog）
四大数据库的日志体系差异
Checkpoint 机制与 Fuzzy Checkpoint
崩溃恢复全过程（影响 MTTR 的因素）
MySQL 的"双一"标准（持久性 + 复制一致性）
Binlog 与 Redo Log 的内部 XA 协调
归档与 PITR

记住三句话：
  1. WAL 是数据库持久性的根基——数据页刷盘前必须先写日志
  2. Checkpoint 是恢复时间的"分水岭"——之前的不重做
  3. MySQL 同时有 Redo 和 Binlog 是历史包袱，但要靠内部 XA 保证一致

下一篇进入复制与高可用：MySQL MGR、PostgreSQL 流复制、SQL Server AlwaysOn、Oracle ADG/RAC，以及共识协议（Paxos / Raft）。

数据库系列（六）：锁与并发控制 — 从行锁到死锁检测

Sun, 14 Jun 2026 20:00:00 +0800

写在前面

承接前一篇 MVCC，本文继续讨论并发控制——但聚焦锁。MVCC 解决"读写并发"，锁解决"写写并发"。

本文要回答：

行锁到底是怎么实现的？SQL Server 为什么会"锁升级"？InnoDB 的 Gap Lock 到底锁了什么？PostgreSQL 怎么用 Advisory Lock 做分布式锁？

一、锁粒度层级

1.1 多层级的锁

数据库 → 表 → 页 / Extent → 行

层级关系：
  上层加意向锁（IS/IX），下层加实际锁（S/X）
  → 加行锁前，先在表上加意向锁

为什么不直接锁行？
  - 防止"表级操作（DROP TABLE）"看不到正在进行的行锁
  - 意向锁是一种"快速检测冲突"的机制

1.2 锁模式矩阵

锁模式	含义	兼容
S（Shared）	共享锁，读用	与 S、IS、IX 兼容
X（Exclusive）	排他锁，写用	与所有锁互斥
IS（Intent Shared）	意向共享	与 IS、IX、S 兼容
IX（Intent Exclusive）	意向排他	与 IS、IX 兼容

兼容性矩阵（行级 / 表级）：
        S    X    IS   IX
   S    ✅   ❌   ✅   ❌
   X    ❌   ❌   ❌   ❌
   IS   ✅   ❌   ✅   ✅
   IX   ❌   ❌   ✅   ✅

关键观察：
  - S 和 X 互斥（读和写不能同时）
  - X 和任何锁互斥（写需要独占）
  - IS 和 IX 互相兼容（意向只是"标记"，不实际锁定）
  - S 和 IX 不兼容（表级 S 锁阻止 IX，因为 IX 暗示有行级 X 锁）

二、SQL Server 的锁体系

SQL Server 是四家里锁体系最复杂的，因为它不依赖 MVCC（默认情况下），用锁解决所有并发。

2.1 多粒度锁

SQL Server 锁粒度：
  - RID（行 ID，堆表）
  - KEY（索引键，clustered/nonclustered）
  - PAGE（页）
  - EXTENT（区，8 页）
  - HoBT（堆或 B 树）
  - TABLE（表）
  - FILE（文件）
  - DATABASE（数据库）

→ SQL Server 会自动选择锁粒度（行/页/表），称为"动态锁"

2.2 锁升级（Lock Escalation）

SQL Server 的"特点"：
  每个事务持有过多锁时，自动升级粒度
  - 行锁 → 页锁
  - 页锁 → 表锁

阈值：单语句持锁超过 5000 个

问题：
  - 升级后锁范围变大，并发变差
  - "我的 SELECT 突然阻塞了所有写入" 这种诡异问题

-- 查看锁
SELECT * FROM sys.dm_tran_locks
WHERE resource_database_id = DB_ID();

-- 禁用表锁升级
ALTER TABLE t SET (LOCK_ESCALATION = DISABLE);

-- 升级到 partition 而非 table
ALTER TABLE t SET (LOCK_ESCALATION = AUTO);

2.3 其他三家的对比

Oracle / MySQL / PostgreSQL：不锁升级
  - 一旦行锁就锁到底（即使持 100 万行锁也不升表锁）
  - 锁管理器设计成可以处理海量锁
  - SQL Server 因为历史原因（早期内存紧张）做了升级

代价：
  - Oracle / PG 内存占用高（每行锁一个 entry）
  - 但并发性更好

三、InnoDB 的行锁三档

InnoDB 的锁是四家里最精巧的，因为它要同时支持 RR（防幻读）和高并发。

3.1 三种行锁

Record Lock（记录锁）：
  锁定索引上的一条记录
  WHERE id = 5 → 锁 id=5 的索引节点

Gap Lock（间隙锁）：
  锁定索引上的"区间"，但不含端点
  WHERE id > 5 AND id < 10 → 锁 (5, 10) 间隙
  防止其他事务在这个区间 INSERT

Next-Key Lock（Next-Key = Record + Gap）：
  锁定"一条记录 + 该记录之前的间隙"
  WHERE id BETWEEN 5 AND 10 → 锁 (3, 5], (5, 8], (8, 10] 等多个 Next-Key

3.2 加锁规则（RR 隔离级别下）

InnoDB RR 下的加锁规则（基于《MySQL 实战 45 讲》）：

1. 原则 1：基本单位是 Next-Key Lock
2. 原则 2：查找过程中访问到的对象才加锁
3. 优化 1：唯一索引等值查询，命中记录 → 退化为 Record Lock
4. 优化 2：等值查询，向右遍历到最后一个不满足条件的值 → Next-Key 退化为 Gap Lock
5. 唯一索引范围查询：会访问到不满足条件的第一个值

示例表：id (1, 5, 10, 15, 20)，主键

场景 1：等值命中唯一索引
  SELECT * FROM t WHERE id = 10 FOR UPDATE;
  → 锁 id=10 的 Record Lock（不锁间隙）

场景 2：等值未命中唯一索引
  SELECT * FROM t WHERE id = 7 FOR UPDATE;
  → 锁 (5, 10) 的 Gap Lock（防止插入 7）

场景 3：范围查询
  SELECT * FROM t WHERE id >= 10 AND id < 15 FOR UPDATE;
  → 锁 [10, 15) 的 Next-Key + 锁 (10, 15) 的 Gap

场景 4：SELECT * FROM t WHERE id > 10 FOR UPDATE;
  → 锁 (10, 15], (15, 20], (20, +∞]

3.3 唯一索引 vs 非唯一索引的差异

唯一索引等值命中 → Record Lock（窄）
非唯一索引等值命中 → Next-Key（多个 Gap）

为什么？
  - 唯一索引：相同值只能有一个，不需要防止"再插一个相同值"
  - 非唯一索引：可能有多条相同值记录，需要锁定间隙防止幻读

3.4 RC 级别下

RC 级别下，InnoDB 退化为只加 Record Lock：
  - 没有 Gap Lock
  - 没有 Next-Key Lock
  - 不防幻读
  - 并发性更好

四、PostgreSQL 的锁

4.1 表级锁

LOCK TABLE t IN {MODE} MODE;

模式（强度递增）：
  ACCESS SHARE        ← SELECT 自动加
  ROW SHARE           ← SELECT FOR UPDATE/SHARE 自动加
  ROW EXCLUSIVE       ← INSERT/UPDATE/DELETE 自动加
  SHARE UPDATE EXCL   ← VACUUM 自动加
  SHARE               ← CREATE INDEX 自动加
  SHARE ROW EXCL      ← 手动
  EXCLUSIVE           ← 手动
  ACCESS EXCLUSIVE    ← ALTER/DROP/TRUNCATE 自动加

4.2 行级锁

PG 行级锁类型：
  FOR UPDATE       ← 排他，允许其他事务读，阻止写
  FOR NO KEY UPDATE ← 排他（弱），允许其他 FOR KEY SHARE
  FOR SHARE        ← 共享
  FOR KEY SHARE    ← 共享（弱）

PG 行锁不存独立结构，记录在行的 xmax：
  - 优点：节省内存（不限制锁数量）
  - 缺点：检查冲突需要读行（多版本查询）

4.3 Advisory Lock（应用层分布式锁）

-- 会话级 Advisory Lock
SELECT pg_advisory_lock(12345);     -- 申请锁
SELECT pg_advisory_unlock(12345);   -- 释放

-- 事务级 Advisory Lock（事务结束自动释放）
SELECT pg_advisory_xact_lock(12345);

-- 非阻塞尝试
SELECT pg_try_advisory_lock(12345);  -- 返回 true/false

-- 双 int 参数版本（支持 8 字节 key）
SELECT pg_advisory_lock(id1, id2);

应用场景：
  - 应用层分布式锁（避免引入 Redis / ZooKeeper）
  - 跨服务协调（多个服务连同一 PG）
  - 任务调度（多个 worker 抢任务）

优势：
  - 与业务事务原子性一致（事务级）
  - 不需要额外基础设施
  - 自动释放（连接断开 / 事务结束）

劣势：
  - 只能在 PG 内有效
  - 不适合跨数据库场景

五、Oracle 的锁

5.1 DML 锁

Oracle 行锁：
  - 通过 ITL（块的事务槽）实现
  - 锁信息存在数据块头部，不存独立结构
  - 不会"锁升级"

锁模式：
  - RX（Row Exclusive）：INSERT/UPDATE/DELETE
  - RS（Row Shared）：SELECT FOR SHARE
  - SRX（Shared Row Exclusive）：手工声明
  - S（Shared）：手工声明
  - X（Exclusive）：手工声明

5.2 DDL 锁

DDL 操作时锁定 schema 对象：
  - Exclusive DDL Lock：CREATE/ALTER/DROP 时，完全独占
  - Share DDL Lock：CREATE PROCEDURE 等，允许其他 DDL 但不允许 DROP
  - Breakable Parse Lock：缓存依赖关系

5.3 Oracle 没有锁升级

Oracle 设计哲学：
  - 锁信息存在数据块里，不占专门内存
  - 一行锁 = 块头部 ITL 的一项（几字节）
  - 100 万行锁也只是 100 万个 ITL entry
  - 永不升级

六、SELECT FOR UPDATE 家族

6.1 标准语法

-- 标准
SELECT * FROM t WHERE id = 1 FOR UPDATE;
-- 加 X 锁，其他事务读可（MVCC），写不行

SELECT * FROM t WHERE id = 1 FOR SHARE;
-- 加 S 锁，其他事务可以读，但不能写

6.2 NOWAIT / SKIP LOCKED

-- NOWAIT：拿不到锁立即报错
SELECT * FROM t WHERE id = 1 FOR UPDATE NOWAIT;
-- 错误：ORA-00054 / Lock wait timeout exceeded

-- SKIP LOCKED：跳过被锁的行（不阻塞）
SELECT * FROM t WHERE id IN (1, 2, 3) FOR UPDATE SKIP LOCKED;
-- 假设 id=2 被锁，返回 id=1 和 id=3

-- 用途：任务队列
SELECT * FROM task_queue WHERE status = 'pending'
FOR UPDATE SKIP LOCKED LIMIT 10;
-- 多个 worker 同时取任务，互不阻塞

支持情况：
  - Oracle：NOWAIT ✅ / SKIP LOCKED ✅
  - SQL Server：NOWAIT ✅（WITH NOWAIT）/ SKIP LOCKED ✅（READPAST）
  - MySQL：NOWAIT ✅（8.0+）/ SKIP LOCKED ✅（8.0+）
  - PostgreSQL：NOWAIT ✅ / SKIP LOCKED ✅

6.3 锁列（FOR UPDATE OF）

1
2
3

-- 联合查询时只锁特定表
SELECT * FROM orders o JOIN users u ON o.uid = u.id
FOR UPDATE OF o;  -- 只锁 orders 行，不锁 users

七、死锁

7.1 死锁场景

事务A                          事务B
BEGIN;                         BEGIN;
UPDATE t SET v=1 WHERE id=1;   UPDATE t SET v=1 WHERE id=2;
                               -- 持有 id=2 锁
UPDATE t SET v=1 WHERE id=2;
-- 等待 id=2 锁                  UPDATE t SET v=1 WHERE id=1;
                                -- 等待 id=1 锁

→ 死锁！双方互相等待

7.2 检测机制

Wait-For Graph（等待图）：
  - 数据库维护一个"事务等待关系图"
  - 检测图中是否有环
  - 有环 → 死锁
  - 选择"代价最小"的事务回滚（victim）

各家实现：
  - Oracle：自动检测，回滚代价最小的事务（错误 ORA-00060）
  - SQL Server：自动检测，默认 5 秒间隔
  - MySQL InnoDB：自动检测，立即回滚（默认 deadlock_detect=ON）
  - PostgreSQL：自动检测，默认 1 秒间隔

7.3 如何避免死锁

1. 固定加锁顺序
   - 所有事务按相同顺序加锁（如按主键升序）
   - 避免环

2. 缩短事务
   - 持锁时间短，降低死锁概率
   - 不要在事务中调用外部 API

3. 用 NOWAIT + 重试
   - 拿不到锁立即失败
   - 应用层捕获错误后重试

4. 用 SKIP LOCKED
   - 任务队列场景，跳过被锁任务

5. 控制并发度
   - 同一资源并发不要太高

八、悲观锁 vs 乐观锁

8.1 悲观锁（Pessimistic）

假设冲突必然发生，提前加锁
  SELECT * FROM t WHERE id = 1 FOR UPDATE;
  -- 加锁后才修改
  UPDATE t SET v = ... WHERE id = 1;
  COMMIT;

适合：写冲突频繁
代价：持锁期间其他事务阻塞

8.2 乐观锁（Optimistic）

假设冲突很少，提交时检测

实现：版本号 / 时间戳字段
  CREATE TABLE t (id INT, v INT, version INT);

  -- 读
  SELECT id, v, version FROM t WHERE id = 1;
  -- 假设读到 version = 10

  -- 写（带版本检查）
  UPDATE t SET v = v + 1, version = version + 1
  WHERE id = 1 AND version = 10;
  -- 影响行数 = 0 → 说明版本变了 → 冲突
  -- 应用层重试

适合：读多写少、冲突少
代价：失败时需要重试

8.3 选型建议

冲突率高（>20%）→ 悲观锁（减少重试开销）
冲突率低 → 乐观锁（避免锁开销）

业务场景：
  - 库存扣减：悲观（必然冲突）
  - 用户更新资料：乐观（极少冲突）
  - 抢购：悲观 + 队列
  - 投票计数：乐观 + 重试

九、常见锁问题排查

9.1 MySQL

-- 看当前事务
SELECT * FROM information_schema.innodb_trx;

-- 看锁（8.0+）
SELECT * FROM performance_schema.data_locks;
SELECT * FROM performance_schema.data_lock_waits;

-- 死锁日志
SHOW ENGINE INNODB STATUS\G

-- 锁等待超时
SHOW VARIABLES LIKE 'innodb_lock_wait_timeout';

9.2 PostgreSQL

-- 看锁
SELECT l.locktype, l.relation::regclass, l.pid, l.mode, l.granted, a.query
FROM pg_locks l
JOIN pg_stat_activity a ON l.pid = a.pid
WHERE NOT l.granted;

-- 看等待链
SELECT * FROM pg_stat_activity WHERE wait_event_type = 'Lock';

-- 杀会话
SELECT pg_terminate_backend(pid);

9.3 Oracle

-- 看锁
SELECT s.sid, s.serial#, l.type, l.mode_held, o.object_name
FROM v$lock l
JOIN v$session s ON l.sid = s.sid
JOIN dba_objects o ON l.id1 = o.object_id
WHERE l.type = 'TM';

-- 杀会话
ALTER SYSTEM KILL SESSION 'sid,serial#';

9.4 SQL Server

-- 看阻塞
SELECT * FROM sys.dm_exec_requests WHERE blocking_session_id <> 0;

-- 看锁
SELECT * FROM sys.dm_tran_locks WHERE request_status = 'WAIT';

十、小结

本文学习了锁与并发控制：

锁粒度层级：DB → 表 → 页 → 行
锁模式矩阵：S/X/IS/IX 的兼容性
SQL Server 的锁升级机制（5000 行阈值）
InnoDB 的三档锁：Record / Gap / Next-Key
InnoDB RR 下的加锁规则
PostgreSQL 的 Advisory Lock（应用层分布式锁）
Oracle 的 ITL 实现行锁
SELECT FOR UPDATE 家族（NOWAIT / SKIP LOCKED）
死锁的 Wait-For Graph 检测
悲观锁 vs 乐观锁

记住三句话：
  1. MVCC 解决读写并发，锁解决写写并发
  2. SQL Server 唯一会锁升级，其他三家锁到底
  3. InnoDB 的 Next-Key Lock 是"为了 RR 防幻读"的代价

下一篇进入日志与崩溃恢复：ARIES 协议、WAL、Checkpoint、崩溃恢复流程，以及四大数据库的日志实现差异。

数据库系列（五）：MVCC 与隔离级别 — 为什么数据库不再读阻塞写

Sun, 14 Jun 2026 19:00:00 +0800

写在前面

承接事务主题，本文深入 ACID 中的 I——隔离性。MVCC（多版本并发控制）是现代数据库读写并发的核心机制，它让"读不阻塞写、写不阻塞读"成为可能。

本文要回答：

为什么 SQL 标准定义的四个隔离级别，各家数据库实现的行为却不一样？为什么 MySQL Repeatable Read 能防幻读，PostgreSQL 不能？为什么 PostgreSQL 表会膨胀？

一、并发问题：标准定义的四种异常

SQL 标准定义了四种并发异常，按严重程度递减：

1.1 脏读（Dirty Read）

事务 A 读到了事务 B 未提交的修改。

时间线：
  T1: 事务B：UPDATE balance SET bal = bal - 100 WHERE id=1;  (未提交)
  T2: 事务A：SELECT bal FROM balance WHERE id=1;  → 读到 -100 后的值
  T3: 事务B：ROLLBACK;
  → A 读到了"从未存在"的值

几乎所有现代数据库都默认不允许脏读。

1.2 不可重复读（Non-repeatable Read）

事务 A 同一行读两次，结果不同（其他事务已提交）。

时间线：
  T1: 事务A：SELECT bal FROM balance WHERE id=1;  → 1000
  T2: 事务B：UPDATE balance SET bal = 900 WHERE id=1; COMMIT;
  T3: 事务A：SELECT bal FROM balance WHERE id=1;  → 900
  → A 两次读结果不同

1.3 幻读（Phantom Read）

事务 A 同一查询两次，结果集行数不同（其他事务插入/删除了匹配行）。

时间线：
  T1: 事务A：SELECT * FROM users WHERE age > 18;  → 10 行
  T2: 事务B：INSERT INTO users (age) VALUES (20); COMMIT;
  T3: 事务A：SELECT * FROM users WHERE age > 18;  → 11 行
  → A 多了一行"幻影"

1.4 丢失更新（Lost Update）

两个事务都基于读到的旧值更新，后写的覆盖前写的。

  T1: 事务A：读 bal = 1000
  T2: 事务B：读 bal = 1000
  T3: 事务A：写 bal = 1000 + 100 = 1100
  T4: 事务B：写 bal = 1000 + 200 = 1200
  → A 的更新丢失

SQL 标准没列这个，但所有数据库都要处理。

1.5 异常矩阵

隔离级别	脏读	不可重复读	幻读	丢失更新
Read Uncommitted	✅	✅	✅	✅
Read Committed（RC）	❌	✅	✅	✅
Repeatable Read（RR）	❌	❌	✅	✅
Serializable	❌	❌	❌	❌

二、MVCC 基本原理

2.1 朴素的锁方案

读：加共享锁 S
写：加排他锁 X
S-X 互斥，X-X 互斥

问题：写事务持有 X 锁期间，所有读都被阻塞
  - 长事务写入 → 大量 SELECT 等待
  - 实际不可用

2.2 MVCC 思路

核心：每行有多个版本，每个事务看到自己"快照"

UPDATE 不修改原行，而是：
  1. 把原行标记为"旧版本"
  2. 写入新行（新版本）
  3. 不同事务根据"可见性规则"看到不同版本

  事务A（开始早）→ 看到旧版本
  事务B（开始晚）→ 看到新版本

→ 读和写不冲突！
→ 性能远高于锁方案

2.3 MVCC 的代价

代价 1：存储膨胀
  - 旧行版本不能立即删
  - 等到所有"可能看到旧行"的事务结束后才能清理
  - PostgreSQL 这点尤其严重（详见第 7 节）

代价 2：写放大
  - 一次 UPDATE = 写一行 + 标记旧行 + 更新索引
  - 比直接"原地改"成本高

代价 3：长事务问题
  - 长事务持有"旧版本"，导致 Undo/WAL 不能清理
  - 拖累整个实例

三、四种 MVCC 实现

四家的 MVCC 实现思路类似（多版本 + 可见性判断），但具体机制不同。

3.1 Oracle：Undo Segment + SCN

核心机制：
  - 每行有"块头 ITL（事务槽）"，记录最后修改它的事务
  - Undo Segment 存"旧版本"
  - SCN（System Change Number）：全局递增的事务编号

可见性判断：
  - 事务开始时记录一个"快照 SCN"
  - 读行时：
    - 行的 ITL SCN ≤ 快照 SCN → 可见
    - 行的 ITL SCN > 快照 SCN → 不可见，去 Undo Segment 找旧版本
    - 一直往回找，直到找到 ≤ 快照 SCN 的版本

查询流程：
  SELECT balance FROM accounts WHERE id = 1;

  1. 读到当前行的 balance = 900，ITL SCN = 200
  2. 我的快照 SCN = 150
  3. 200 > 150 → 不可见
  4. 通过 ITL 找到 Undo Segment 中 SCN = 100 的旧版本 balance = 1000
  5. 100 ≤ 150 → 可见，返回 1000

3.2 MySQL InnoDB：Undo Log + ReadView

核心机制：
  - 每行隐藏两个列：DB_TRX_ID（最后修改事务 ID）、DB_ROLL_PTR（指向 Undo 链）
  - Undo Log 中存旧版本，通过 DB_ROLL_PTR 串成链
  - ReadView：事务开始时创建的"快照"

ReadView 内容：
  - m_ids：当前活跃（未提交）事务 ID 列表
  - min_trx_id：m_ids 最小值
  - max_trx_id：下一个要分配的事务 ID
  - creator_trx_id：创建 ReadView 的事务 ID

可见性判断：
  - 行的 trx_id < min_trx_id → 该事务已提交 → 可见
  - 行的 trx_id >= max_trx_id → 该事务在我之后开始 → 不可见
  - 行的 trx_id 在 m_ids 中 → 该事务未提交 → 不可见
  - 行的 trx_id == creator_trx_id → 自己改的 → 可见
  - 否则 → 可见

RC vs RR 的实现差异：
  - Read Committed：每条 SELECT 都创建新 ReadView
    → 总是看到最新已提交数据
    → 但同一事务内同一行可能看到不同值（不可重复读）
  - Repeatable Read：事务内只创建一次 ReadView（第一次读时）
    → 整个事务看到的数据快照一致
    → 不会发生不可重复读

3.3 PostgreSQL：xmin/xmax + clog

核心机制：
  - 每行有 xmin（创建事务 ID）和 xmax（删除/更新事务 ID）
  - 没有独立 Undo，旧行就留在 Heap 里
  - clog（commit log）：记录每个事务的状态（committed/aborted/in-progress）

可见性判断：
  - 行的 xmin 已提交且 < 当前快照 → 可见
  - 行的 xmax 已提交且 ≤ 当前快照 → 已被删除，不可见
  - 复杂规则见 PostgreSQL 源码 HeapTupleSatisfiesMVCC

特点：
  - 不需要 Undo Log
  - 旧 tuple 直接留在 heap 中（"表膨胀"）
  - VACUUM 后台清理

3.4 SQL Server：RCSI / SI（基于 TempDB）

核心机制：
  - 行版本存在 TempDB（不是本表）
  - 两种模式：
    RCSI（Read Committed Snapshot Isolation）：
      - Read Committed 默认走行版本
      - 每条语句一个快照
    SI（Snapshot Isolation）：
      - 类似 RR，整个事务一个快照
      - 需要应用显式启用

启用：
  ALTER DATABASE mydb SET READ_COMMITTED_SNAPSHOT ON;  -- RCSI
  ALTER DATABASE mydb SET ALLOW_SNAPSHOT_ISOLATION ON;  -- SI

注意：
  - SQL Server 默认 RC 是"读加 S 锁"，不是 MVCC
  - 启用 RCSI 后才变成 MVCC 行为

3.5 四家对比

维度	Oracle	SQL Server	MySQL InnoDB	PostgreSQL
旧版本存放	Undo Segment	TempDB	Undo Log	Heap 内
事务标识	SCN	TID	DB_TRX_ID	xmin/xmax
清理机制	SMON 自动	TempDB 自动	Purge Thread	autovacuum
默认隔离级别	Read Committed	Read Committed	Repeatable Read	Read Committed
RR 防幻读	✅（Serializable）	❌	✅	❌

四、幻读与 Next-Key Lock

4.1 MySQL InnoDB 的 RR：为什么能防幻读

InnoDB 在 RR 级别下，普通 SELECT 用 MVCC（快照读），不会幻读
但 UPDATE/DELETE/SELECT FOR UPDATE 用当前读，要靠锁防幻读

Next-Key Lock = Gap Lock + Record Lock

示例：
  表：id (1, 5, 10, 15, 20)
  索引：id 主键

  事务A：SELECT * FROM t WHERE id BETWEEN 5 AND 15 FOR UPDATE;
  → 锁住 id ∈ [5, 15] 的所有行（Record Lock）
  → 同时锁住 (15, 20) 之间的"间隙"（Gap Lock）
  → 防止其他事务插入 id ∈ (10, 15) 或 (15, 20)

  事务B：INSERT INTO t VALUES (12);
  → 阻塞（Gap Lock 拦截）

Gap Lock 的副作用：
  - 锁范围比"实际行"大
  - 高并发插入场景容易死锁
  - 唯一索引等值查询会"退化"（不需要 Gap Lock）

4.2 PostgreSQL 的 RR：不能防幻读

PG 的 RR 完全基于 MVCC，没有 Gap Lock：
  - 整个事务一个快照
  - 重复读不会变化（不会不可重复读）
  - 但其他事务插入的新行，事务后期能看到（幻读）

  事务A：SELECT * FROM t WHERE id > 10;  → 3 行
  事务B：INSERT INTO t VALUES (15); COMMIT;
  事务A：SELECT * FROM t WHERE id > 10;  → 4 行 ← 幻读！

PG 怎么防幻读？
  → 用 Serializable 级别（SSI 实现）
  → 通过 SIREAD 锁 + 冲突检测
  → 性能代价大

4.3 SQL Server：SI 同样不防幻读

SI（Snapshot Isolation）：类似 PG 的 RR
  - 不会不可重复读
  - 但会幻读
  - 写冲突时报错（需要重试）

要防幻读 → Serializable

五、Serializable 的"真假"

5.1 真 Serializable vs SSI

真 Serializable：
  - 表级锁 / 范围锁
  - 性能极差，几乎不用
  - 2PL（Two-Phase Locking）的严格实现

SSI（Serializable Snapshot Isolation）：
  - PostgreSQL 9.1+、SQL Server（部分）
  - 基于 MVCC + 冲突检测
  - 性能远好于传统 Serializable
  - 但仍有写冲突代价

5.2 各家 Serializable 实现

数据库	实现	性能
Oracle	表/范围锁	差（生产几乎不用）
SQL Server	范围锁	差
MySQL InnoDB	2PL + Next-Key Lock	中
PostgreSQL	SSI	较好

5.3 实践建议

默认隔离级别选择：
  - Oracle / SQL Server / PG → Read Committed（默认）
  - MySQL InnoDB → Repeatable Read（默认）

需要"严格串行化"：
  - 高一致性场景（金融）→ Serializable
  - 否则 RC/RR 已经够用

PG SSI 用法：
  SET default_transaction_isolation = 'serializable';
  -- 业务代码需要重试机制（写冲突会报错）

六、Read Committed 的细节差异

6.1 Oracle / PG 的 RC：语句级快照

每条 SELECT 创建一个新快照，看到当时最新已提交数据。

  事务A：
    SELECT * FROM t WHERE id = 1;  -- 假设看到 value = 100
    [其他事务改并提交 value = 200]
    SELECT * FROM t WHERE id = 1;  -- 看到 value = 200

6.2 MySQL InnoDB 的 RC：与 Oracle/PG 类似

InnoDB 在 RC 级别下：
  - 每条 SELECT 创建新 ReadView
  - 不能 Next-Key Lock（退化到 Record Lock）
  - 不能防不可重复读

6.3 SQL Server 默认 RC：基于锁

SQL Server 默认 RC 是"读加 S 锁"：
  - SELECT 期间持 S 锁
  - 写事务被阻塞
  - 不是 MVCC

启用 RCSI 后变成 MVCC（语句级快照）：
  ALTER DATABASE mydb SET READ_COMMITTED_SNAPSHOT ON;
  -- 这是 SQL Server 性能优化关键步骤

七、PostgreSQL 表膨胀与 VACUUM

7.1 为什么 PG 会膨胀

PG 没有 Undo Segment，旧 tuple 留在 heap：
  UPDATE → 插入新 tuple + 标记旧 tuple xmax
  旧 tuple 仍在 heap 中，占用空间

  长期高频 UPDATE：
    原表 1GB → 实际有效数据 200MB + 死 tuple 800MB
    → 性能下降（扫描慢、缓存命中率低）

7.2 autovacuum

PG 自动清理死 tuple 的后台进程：
  - 默认启用
  - 每 N 行变更触发一次 VACUUM
  - 关键参数：
    autovacuum_vacuum_threshold = 50（基础行数）
    autovacuum_vacuum_scale_factor = 0.2（变更比例）
    → 满足条件：50 + 表行数 × 0.2

-- 手动触发
VACUUM ANALYZE accounts;     -- 普通 VACUUM + 更新统计
VACUUM FULL accounts;        -- 锁表 + 重写表（回收磁盘空间，慢）
REINDEX TABLE accounts;      -- 重建索引

-- 监控
SELECT relname, n_live_tup, n_dead_tup
FROM pg_stat_user_tables
WHERE n_dead_tup > 10000;

7.3 长事务的危害

PG 长事务的连锁问题：
  1. 旧 tuple 不能被 VACUUM 清理（事务可能还要看到）
  2. clog 不能截断
  3. 复制槽（replication slot）可能阻塞 WAL 删除
  4. 表空间持续膨胀

排查：
  SELECT pid, age(now(), xact_start) AS duration, query
  FROM pg_stat_activity
  WHERE state = 'idle in transaction';

  → 长事务杀掉：SELECT pg_terminate_backend(pid);

八、常见问题排查

8.1 死锁

-- MySQL 看最近一次死锁
SHOW ENGINE INNODB STATUS\G

-- PostgreSQL 看日志
-- 默认会记录：ERROR: deadlock detected

8.2 锁等待

-- MySQL 看锁等待
SELECT * FROM information_schema.innodb_trx;
SELECT * FROM performance_schema.data_locks;

-- PostgreSQL 看锁
SELECT * FROM pg_locks WHERE NOT granted;

8.3 长事务

-- MySQL
SELECT * FROM information_schema.innodb_trx
WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60;

-- PostgreSQL
SELECT pid, xact_start, query
FROM pg_stat_activity
WHERE state IN ('active', 'idle in transaction')
ORDER BY xact_start;

九、小结

本文学习了 MVCC 与隔离级别：

四种并发异常：脏读、不可重复读、幻读、丢失更新
MVCC 的核心：多版本 + 可见性判断
四家 MVCC 实现：Oracle Undo、InnoDB ReadView、PG xmin/xmax、SQL Server TempDB
隔离级别实现差异：MySQL RR 防幻读（Next-Key Lock），PG RR 不防
Serializable 的真假：传统 2PL vs SSI
PostgreSQL 的表膨胀与 VACUUM 机制
长事务的危害

记住三句话：
  1. RC 是语句级快照，RR 是事务级快照，Serializable 是真串行
  2. PG 没有 Undo，旧 tuple 留在 heap → 必须配置 autovacuum
  3. MySQL InnoDB 默认 RR + Next-Key Lock 防幻读，但代价是死锁风险

下一篇进入锁与并发控制：从行锁到死锁检测，深入 InnoDB 的 Record/Gap/Next-Key 三档锁、SQL Server 的锁升级、PostgreSQL 的 Advisory Lock。

数据库系列（四）：事务与 ACID — 从单机原子性到分布式一致性

Sun, 14 Jun 2026 18:00:00 +0800

写在前面

承接前三篇，本文进入第三个子系统：事务。ACID 是关系数据库区别于 NoSQL 最核心的特征，但 A、C、I、D 各自怎么实现？为什么 MySQL 写一条数据要刷三次盘？分布式事务为什么又慢又复杂？

本文横向对比 Oracle、SQL Server、MySQL、PostgreSQL 四家在事务实现上的差异。

一、ACID 严格定义

ACID 是 1983 年 Andreas Reuter 和 Theo Härder 提出的概念：

性质	含义	直觉解释
Atomicity（原子性）	事务要么全部成功，要么全部回滚	“要么都做，要么都不做”
Consistency（一致性）	事务前后数据库满足约束	“钱不会凭空消失或出现”
Isolation（隔离性）	并发事务互不干扰	“你转账时我看到的是旧余额”
Durability（持久性）	提交后数据永久保存	“断电也不丢”

1.1 C 不是引擎保证的

很多人误以为"一致性是数据库做的"，其实不是：
  - 引擎保证 A、I、D
  - C 是"应用 + 约束 + 触发器"共同保证
  - 引擎提供约束（外键、CHECK、唯一）作为工具
  - 但 C 的根本责任在业务代码

举例：
  约束：账户余额不能为负
  事务：UPDATE accounts SET balance = balance - 100 WHERE id = 1;
  - 如果余额只有 50：数据库靠 CHECK 约束拦截（C 由数据库帮助保证）
  - 如果转账总额对不上：数据库无能为力（C 由应用代码保证）

1.2 谁负责实现 A、I、D

性质	实现机制
A	Undo Log（回滚日志）
I	锁 + MVCC（详见第 5、6 篇）
D	Redo Log + WAL + fsync
C	应用 + 数据库约束（外键、CHECK）

本文聚焦 A 和 D，I 留给第 5、6 篇。

二、原子性靠 Undo

2.1 为什么需要 Undo

事务：UPDATE accounts SET balance = balance - 100 WHERE id = 1;
       INSERT INTO log VALUES (...);
       UPDATE summary SET count = count + 1;

如果第二条 INSERT 失败 → 整个事务必须回滚
  → 第 1 条 UPDATE 已经改了内存页 balance
  → 必须知道"原值"才能撤销
  → 这就是 Undo Log 的作用

2.2 Undo 的工作流程

1. 事务开始
2. 修改行之前，先把"旧值"写入 Undo Log
   Undo Log: (tx_001, account.id=1, balance: 1000 → ...)
3. 修改 Buffer Pool 中的数据页（balance 变 900）
4. 后续操作失败 → 用 Undo Log 把 balance 改回 1000
5. 事务提交 → Undo Log 标记为"可清理"
   （但 MVCC 场景下不能立即删，详见第 5 篇）

2.3 四家的 Undo 实现差异

数据库	Undo 存放	命名	特点
Oracle	Undo 表空间（独立段）	Undo Segment	进程可独立管理，能扩能缩
SQL Server	TempDB（短事务）/ 数据库日志	——	长事务 Undo 在 Transaction Log
MySQL InnoDB	Undo TableSpace	Undo Log	5.6+ 独立表空间，5.7+ 可独立配置
PostgreSQL	Heap 表内（旧 tuple）	Old Tuple	不存独立 Undo，靠多版本

关键差异：PG 不用独立 Undo
  - PG 的每行有 xmin/xmax（创建/删除事务 ID）
  - UPDATE = 标记旧行 xmax + 插入新行（新 xmin）
  - 旧 tuple 留在 heap 里，直到 VACUUM 清理
  - 优点：回滚极快（标记 xmax = 0 即可）
  - 缺点：表会"膨胀"，需要 VACUUM 维护

2.4 Savepoint 与嵌套事务

-- 标准 SQL Savepoint
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
SAVEPOINT before_log;
INSERT INTO log VALUES (...);  -- 假设失败
ROLLBACK TO before_log;        -- 只回滚到 Savepoint
-- 第 1 条 UPDATE 仍然有效
INSERT INTO log VALUES ('fallback', ...);  -- 重试
COMMIT;

四家都支持 SAVEPOINT，但真正的嵌套事务只有 Oracle 部分支持（通过 Autonomous Transaction）。其他三家都靠 Savepoint 模拟。

2.5 隐式提交的坑

-- DDL 通常会隐式 COMMIT
BEGIN;
INSERT INTO log VALUES ('test');
CREATE TABLE temp (id INT);  -- 隐式 COMMIT！前一个 INSERT 也被提交
ROLLBACK;  -- 无法回滚 INSERT

隐式 COMMIT 的语句：
  - DDL（CREATE / ALTER / DROP / TRUNCATE）
  - 部分 DCL（GRANT / REVOKE）
  - 部分 ADMIN（ANALYZE / VACUUM in PG 不触发）

各家差异：
  - MySQL：DDL 必隐式 COMMIT（即使是 InnoDB）
  - PostgreSQL：DDL 也可以在事务内（CREATE TABLE 不触发 COMMIT）
  - Oracle：DDL 必隐式 COMMIT
  - SQL Server：DDL 可在事务内

→ PG 这点是优势，可以"事务化 DDL"，回滚 CREATE TABLE 没问题

三、持久性靠 Redo + WAL

3.1 为什么需要 Redo

问题：内存改了，磁盘还没刷
  - Buffer Pool 改了 balance = 900（内存）
  - 数据页还没刷到磁盘
  - 此时断电 → 改动丢失

朴素方案：每次 COMMIT 都把数据页刷盘
  - 一个数据页 16KB
  - 改 1 字节也要刷 16KB
  - 100 个事务改不同行 → 100 次随机 I/O
  - 极慢

正确方案：每次 COMMIT 只刷"Redo Log"
  - Redo Log 只记录"改了什么"（物理日志）
  - 顺序写（追加到日志文件末尾）
  - 一次 fsync 即可
  - 后台异步把数据页刷盘

3.2 WAL（Write-Ahead Logging）

WAL 原则：
  - 数据页刷盘之前，对应的 Redo Log 必须先刷盘
  - 否则崩溃时数据页是"半新半旧"状态，无法恢复

流程：
  1. 改 Buffer Pool（dirty page）
  2. 写 Redo Log Buffer
  3. COMMIT → fsync Redo Log Buffer 到磁盘
  4. 后台：dirty page 缓慢刷盘（每次 checkpoint）
  5. 崩溃恢复：用 Redo Log 重做未刷盘的页

顺序写 vs 随机写：
  - 顺序写：100~300 MB/s（SSD）
  - 随机写：5~50 MB/s（SSD）
  - 差距 10~30 倍

→ 这就是为什么 COMMIT 性能远高于"直接刷数据页"

3.3 四家的 Redo 命名

数据库	Redo Log	关键参数
Oracle	Redo Log（online + archive）	`LOG_BUFFER`、`FAST_START_MTTR_TARGET`
SQL Server	Transaction Log（.ldf）	`recovery interval`、`target_recovery_time`
MySQL	Redo Log（ib_logfile，8.0 改名 ib_redo）	`innodb_flush_log_at_trx_commit`
PostgreSQL	WAL（pg_wal/ 目录）	`wal_level`、`synchronous_commit`

3.4 fsync 的代价

"双一"标准（金融场景）：
  - innodb_flush_log_at_trx_commit = 1：每次 COMMIT 都 fsync Redo Log
  - sync_binlog = 1：每次事务都 fsync Binlog

fsync 性能：
  - HDD：每次 ~10ms（每秒最多 100 个事务）
  - SSD：每次 ~1ms（每秒最多 1000 个事务）
  - NVMe：每次 ~0.1ms（每秒最多 10000 个事务）

优化：
  - Group Commit：多个事务的 COMMIT 合并成一次 fsync
  - 异步 fsync（牺牲持久性换性能）：innodb_flush_log_at_trx_commit = 2

四、Group Commit

4.1 朴素 COMMIT 的性能问题

事务 A → COMMIT → fsync → 等 1ms
事务 B → COMMIT → fsync → 等 1ms
事务 C → COMMIT → fsync → 等 1ms

3 个事务共 3ms

事务 A、B、C 几乎同时到达 → 仍然各自 fsync → 3ms

→ fsync 是顺序的，每次都是磁盘写

4.2 Group Commit 的思路

事务 A、B、C 几乎同时到达：
  1. A 进入队列，成为 Leader
  2. B、C 看到队列有人，加入（成为 Follower）
  3. Leader 把 ABC 的 Redo Log 一次性 fsync
  4. ABC 全部 COMMIT 成功

→ 3 个事务共 1ms（吞吐量 3 倍）

4.3 四家的 Group Commit

数据库	实现名称	关键参数
Oracle	Log Writer Group Commit	自动
SQL Server	Log Writer Grouping	自动
MySQL 5.7+	Binary Log Group Commit	`binlog_group_commit_sync_delay`
PostgreSQL	Group Commit（自动）	`synchronous_commit = on` 配合

1
2
3

-- MySQL：开启 Group Commit
SET GLOBAL binlog_group_commit_sync_delay = 1000;  -- 微秒
SET GLOBAL binlog_group_commit_sync_no_delay_count = 10;  -- 满 10 个立即提交

五、两阶段提交（2PC）

为什么 MySQL InnoDB 有 Redo Log 还有 Binlog？它们怎么协调？

5.1 Binlog vs Redo Log

Redo Log：
  - InnoDB 引擎层
  - 物理日志（"页号 X 偏移 Y 改成 Z"）
  - 用于崩溃恢复
  - 循环写（覆盖式）

Binlog：
  - Server 层
  - 逻辑日志（"行 R 的字段 C 改成 V"）
  - 用于主从复制、数据回放
  - 追加写（不覆盖）

为什么不只用一种？
  - 只用 Redo Log：从库要执行物理日志（页级别），跨版本不兼容
  - 只用 Binlog：崩溃恢复时无法精确重放（Binlog 是逻辑日志，无"页是否刷盘"信息）

→ 两套日志各自有用途，必须协调一致

5.2 内部 2PC 流程

1. InnoDB 改 Buffer Pool，写 Redo Log（内存）
2. 【Prepare 阶段】
   - Redo Log 写入 PREPARE 标记
   - fsync Redo Log
3. 【Server 层】
   - 写 Binlog
   - fsync Binlog
4. 【Commit 阶段】
   - Redo Log 写入 COMMIT 标记
   - fsync Redo Log
5. 返回客户端成功

5.3 崩溃恢复时怎么处理

重启后扫描 Redo Log：
  - 找到所有"PREPARE 但没 COMMIT"的事务
  - 检查 Binlog 是否完整：
    - Binlog 已写完整 → 重做该事务（保证主从一致）
    - Binlog 不完整 → 回滚该事务

→ 这就是"MySQL 内部 XA"——保证 Redo Log 和 Binlog 一致

5.4 半同步复制用到了 2PC

半同步复制（Semi-Sync）：
  - 主库 COMMIT 时，至少一个从库 ACK 收到 Binlog
  - 否则主库降级为异步复制

阶段：
  1. 主库 PREPARE
  2. 主库写 Binlog
  3. 主库推送 Binlog 到从库
  4. 从库 ACK
  5. 主库 COMMIT

六、分布式事务

跨多个数据库实例的事务，需要外部协调。

6.1 XA 标准

XA = X/Open DTP 模型
  - TM（Transaction Manager）：协调者
  - RM（Resource Manager）：参与者（数据库）
  - 通信协议：两阶段提交（2PC）

阶段 1：Prepare
  TM → 各 RM：PREPARE
  各 RM → TM：OK / FAIL

阶段 2：Commit / Rollback
  全部 OK → TM → 各 RM：COMMIT
  任一 FAIL → TM → 各 RM：ROLLBACK

6.2 四家的分布式事务实现

Oracle：XA 接口（OCI）
  - 长期支持 X/Open XA
  - 跨多个 Oracle DB 或异构数据源

SQL Server：MSDTC（Microsoft Distributed Transaction Coordinator）
  - Windows 系统服务
  - .NET 通过 TransactionScope 使用
  - 跨多个 SQL Server 或异构数据源

MySQL：XA 协议
  - XA START 'xid'; ... XA END 'xid'; XA PREPARE 'xid'; XA COMMIT 'xid';
  - 性能较差，生产较少使用
  - 通常用业务层 TCC / SAGA 替代

PostgreSQL：Prepared Transaction
  - PREPARE TRANSACTION 'xid'; COMMIT PREPARED 'xid';
  - 实现标准 2PC
  - max_prepared_transactions 控制上限

-- PG 2PC 示例
BEGIN;
UPDATE account_a SET balance = balance - 100 WHERE id = 1;
PREPARE TRANSACTION 'transfer_001';
-- 此处可以连接另一个数据库做对应操作
-- 完成后：
COMMIT PREPARED 'transfer_001';
-- 或者失败：
ROLLBACK PREPARED 'transfer_001';

6.3 2PC 的痛点

1. 同步阻塞
   - PREPARE 后所有 RM 锁定资源，直到 COMMIT
   - 一个慢节点拖垮整个事务

2. 协调者单点
   - TM 挂了 → 参与者卡在 PREPARE 状态
   - 数据锁死，需要人工干预

3. 数据不一致（极端情况）
   - 阶段 2 时部分 RM 收到 COMMIT，部分没收到
   - 需要"重试 + 补偿"机制

4. 性能差
   - 多次网络往返
   - 锁定时间长

6.4 替代方案：TCC 与 SAGA

TCC（Try-Confirm-Cancel）：
  - 业务层补偿事务
  - Try：预留资源（如冻结余额）
  - Confirm：确认（扣减冻结）
  - Cancel：取消（解冻）
  - 性能好，但侵入业务

SAGA：
  - 长事务拆成多个本地事务
  - 每个本地事务有对应的"补偿事务"
  - 失败时按逆序补偿
  - 最终一致性

本地消息表：
  - 业务表 + 消息表同事务写入
  - 后台扫描消息表，推送到 MQ
  - 下游消费后回调
  - 解耦性强，最常用

七、实战：不同持久性级别的权衡

7.1 MySQL 的 innodb_flush_log_at_trx_commit

-- 值含义：
0 = 每秒 fsync Redo Log（崩溃可能丢 1 秒数据）
1 = 每次 COMMIT fsync Redo Log（最安全，最慢）  ← 默认
2 = 每次 COMMIT 写 OS Cache，每秒 fsync（OS 崩溃丢数据）

实测性能（同硬件，1000 个事务）：
  - 0：1 秒
  - 1：30 秒
  - 2：3 秒

→ 0 和 2 性能好但都不"金融级安全"
→ 1 是必须的双一标准之一

7.2 PostgreSQL 的 synchronous_commit

-- 值含义：
off  = 不等待 fsync（极快，可能丢事务）
local = 等待本地 fsync（默认）
on   = 等待本地 + 同步副本 fsync
remote_write = 等待副本写入 OS Cache
remote_flush = 等待副本 fsync

-- 可在会话级调整
SET synchronous_commit = off;  -- 临时降低持久性换性能

7.3 事务隔离级别速览

留给第 5 篇深入，这里先列出名称：

隔离级别	脏读	不可重复读	幻读
Read Uncommitted	✅	✅	✅
Read Committed	❌	✅	✅
Repeatable Read	❌	❌	部分解决
Serializable	❌	❌	❌

八、小结

本文学习了事务与 ACID：

ACID 各性质的实现责任：引擎做 A/I/D，应用做 C
原子性靠 Undo Log（PG 用多版本 tuple）
持久性靠 Redo Log + WAL + fsync
顺序写 fsync 是性能瓶颈，Group Commit 是核心优化
MySQL 的内部 XA：Redo Log 与 Binlog 的两阶段提交
分布式事务的 XA 标准、痛点与替代方案（TCC / SAGA / 本地消息表）
持久性 vs 性能的权衡参数

记住三句话：
  1. A 靠 Undo，D 靠 Redo，C 靠约束，I 靠锁 + MVCC
  2. COMMIT 慢的本质是 fsync，Group Commit 是关键
  3. 分布式事务能用本地消息表就别用 XA

下一篇进入隔离性的核心机制——MVCC，深入 Oracle SCN、InnoDB ReadView、PG xmin/xmax 的实现差异。

数据库系列（三）：索引原理 — B+ 树、位图、倒排与四大数据库的实现差异

Sun, 14 Jun 2026 17:00:00 +0800

写在前面

承接前一篇存储引擎的内容，本文进入第二个子系统：索引。索引是数据库性能的核心——一个表加对索引可以让查询从秒级降到毫秒级，加错索引也能让写入变成灾难。

本文要回答的核心问题：

为什么几乎所有关系数据库的索引都是 B+ 树？PG 的 GIN/GiST/BRIN 是什么？为什么联合索引要最左前缀？

一、为什么是 B+ 树

1.1 一个朴素问题

100 万行的表，按 id 查询：

方案 1：顺序扫描（Seq Scan）
  平均读 50 万行 → 几百毫秒

方案 2：哈希索引（Hash Index）
  哈希一次 → O(1) 找到行
  限制：只支持等值查询（=、IN），范围查询不支持

方案 3：二叉搜索树（BST）
  高度 log2(100万) ≈ 20
  每次比较一次 + 读一个节点 → 20 次 I/O（如果每节点一页）
  限制：树太高，磁盘 I/O 多

方案 4：B 树（B-Tree）
  多叉树，每节点存多个 key + 数据
  高度 logm(N)，m 通常 100+ → 100 万行高度 2~3
  限制：内部节点也存数据 → 节点能放的 key 数少 → 树高较高

方案 5：B+ 树（B+Tree）
  B 树的变种：所有数据只在叶子节点
  内部节点只放 key，叶子节点放完整数据
  叶子节点之间用双向链表连接
  → 内部节点能放更多 key，树高更低
  → 范围查询走叶子链表，极快

1.2 B+ 树的结构

                       [10│30│50│70]              ← 根（内部节点，只放 key）
                      /      |       |       \
              [1│3│5│8] [11│15│25│28] [31│38│45│48] [51│55│65│68] [71│75│85│88]
                ↑────────叶子节点链表────────↑
              叶子节点存完整数据（IOT）或行指针（二级索引）

特性：
  - 高度通常 2~4（千万级数据）
  - 范围查询：从根定位到叶子，沿链表扫描
  - 等值查询：从根定位到叶子
  - 每节点 = 一个 Page（默认 8K / 16K）

1.3 为什么 B+ 树胜出

数据结构	等值查询	范围查询	排序	树高（1亿行）
Hash	✅ O(1)	❌	❌	——
二叉 BST	O(log n)	✅ 慢	✅ 慢	27
红黑树	O(log n)	✅ 慢	✅ 慢	27
跳表	O(log n)	✅	✅	27
B 树	O(logm n)	✅	✅	4~5
B+ 树	O(logm n)	✅ 极快	✅ 极快	2~3

B+ 树的核心优势：
  1. 树矮：每节点放百级 key，3 层就能索引亿级行
  2. 范围查询强：叶子链表，连续 I/O
  3. 排序免费：B+ 树本身有序
  4. 节点 = Page：天然适配缓冲池

1.4 跳表的故事：为什么 Redis 用跳表而 MySQL 用 B+ 树

Redis 用跳表（ZSet 底层）：
  - 全内存，I/O 不是瓶颈
  - 跳表实现简单（无锁 CAS 友好）
  - 不在乎树高（27 层和 3 层在内存里差不多）

MySQL 用 B+ 树：
  - 数据在磁盘，I/O 是瓶颈
  - 必须让树矮（3 层就够）
  - 节点要按 Page 组织，匹配磁盘 I/O 单位

一句话：磁盘选 B+ 树，内存选跳表 / 哈希。

二、聚集索引 vs 非聚集索引

承接前一篇的 HEAP vs IOT，索引视角下要再讲一遍，因为这是四大数据库最大的术语混淆点。

2.1 名词对照

概念	Oracle	SQL Server	MySQL InnoDB	PostgreSQL
主键索引（数据本身）	IOT	Clustered Index	Clustered Index	（无，主键也只是索引）
二级索引	Normal Index	Nonclustered Index	Secondary Index	Index
二级索引指向什么	rowid（堆表）/ PK（IOT）	RID（堆）/ Clustered Key	主键值	ctid

2.2 二级索引的"回表"成本

查询：SELECT name, balance FROM accounts WHERE name = 'Alice';

InnoDB：
  1. 走 name 二级索引（B+ 树）→ 找到主键值 id=1
  2. 走主键索引（B+ 树）→ 找到 id=1 的整行（"回表"）
  → 2 次 B+ 树查找

PostgreSQL：
  1. 走 name 索引 → 找到 ctid=(0,1)
  2. 走 Heap → 直接定位到行（"回 heap"）
  → 1 次索引 + 1 次随机读

差异：
  - InnoDB：二级索引查到的主键值，再到主键 B+ 树走一遍
  - PG：二级索引直接给出物理位置，一次定位到 heap
  - 单条查询 PG 通常更省 I/O，但需要二级索引足够"宽"

2.3 SQL Server 的两种表状态

-- 状态 1：堆表（Heap），无 Clustered Index
CREATE TABLE t_heap (id INT, name VARCHAR(50));
-- 二级索引指向 RID（FileID:PageID:SlotID，8 字节）

-- 状态 2：Clustered Table（有 Clustered Index）
CREATE TABLE t_clustered (
    id INT PRIMARY KEY,  -- 自动建 Clustered Index
    name VARCHAR(50)
);
-- 二级索引指向 Clustered Key（id 值）

2.4 Oracle 的 IOT 选项

-- 默认堆表
CREATE TABLE t1 (id INT PRIMARY KEY, name VARCHAR2(50));
-- PK 是独立的二级索引，指向 rowid

-- 显式 IOT
CREATE TABLE t2 (
    id INT PRIMARY KEY,
    name VARCHAR2(50)
) ORGANIZATION INDEX;
-- 表本身就是按 id 排序的 B+ 树

2.5 设计原则

IOT / Clustered Key 的选择原则（适用 InnoDB / MSSQL Clustered / Oracle IOT）：
  1. 短：让所有二级索引都跟着变小
  2. 单调递增：减少 B+ 树页分裂（如自增 ID）
  3. 不变：改主键 → 所有二级索引重建
  4. 唯一：Clustered Key 必须唯一（不唯一时引擎会加后缀）

PG 反而没这些约束：主键可以随意选，因为所有索引都指向 ctid

三、PG 的索引武器库

PostgreSQL 是四家里索引类型最丰富的。除了 B-tree，还有 GIN、GiST、BRIN、SP-GiST、Hash 五种。

3.1 B-tree（默认）

CREATE INDEX idx_name ON t(name);

-- 适用：等值、范围、排序、唯一约束
-- 不适用：JSON 文档检索、全文搜索、地理数据

3.2 GIN（Generalized Inverted Index，倒排索引）

倒排索引：把"元素 → 行"的映射存起来
  适用：数组、JSONB、全文检索

示例表：tags 是 text[]
  id | tags
  ---|------
  1  | {a, b, c}
  2  | {b, c, d}
  3  | {a, c}

GIN 索引内部：
  a → [1, 3]
  b → [1, 2]
  c → [1, 2, 3]
  d → [2]

查询 WHERE 'b' = ANY(tags) → 直接用 GIN，O(log n)

-- 数组索引
CREATE INDEX idx_tags ON t USING GIN(tags);
SELECT * FROM t WHERE tags @> ARRAY['b'];

-- JSONB 索引
CREATE INDEX idx_data ON t USING GIN(data);
SELECT * FROM t WHERE data @> '{"city": "Shanghai"}';

-- 全文索引
CREATE INDEX idx_fts ON docs USING GIN(to_tsvector('english', body));
SELECT * FROM docs WHERE to_tsvector('english', body) @@ to_tsquery('postgres & index');

GIN 特点：
  - 查询快（O(log n)）
  - 写入慢（每条记录要拆成多个元素入索引）
  - 适合"低频更新、高频查询"场景

3.3 GiST（Generalized Search Tree）

GiST 是一个"框架"，可以塞各种数据类型：
  - 地理数据（PostGIS 核心依赖）
  - 范围类型（int4range、tstzrange）
  - 模糊匹配（pg_trgm）

示例：找"附近 1km 的店铺"
CREATE INDEX idx_location ON shops USING GIST(location);
SELECT * FROM shops
WHERE ST_DWithin(location, ST_Point(121.4, 31.2), 1000);

3.4 BRIN（Block Range Index）

BRIN：块范围索引
  适用：超大的、物理顺序与某列相关的表（如按时间追加的日志）

原理：
  每 128 个 Page 一组，记录这组的最小/最大值
  查询时根据 min/max 跳过大块

-- 时序日志场景
CREATE INDEX idx_log_ts ON logs USING BRIN(ts);

SELECT * FROM logs WHERE ts >= '2026-06-01' AND ts < '2026-06-02';
-- BRIN 让 PG 跳过 ts 不在范围的大块

BRIN 特点：
  - 索引极小（KB 级，不是 GB 级）
  - 适合"自然有序"的数据（时间序列）
  - 不适合随机写入的数据

3.5 SP-GiST（Space-Partitioned GiST）

1
2

SP-GiST：用于"非平衡"数据结构（如 trie 树、四叉树、k-d 树）
  适用：电话区号、IP 路由、字符串前缀匹配

3.6 Hash

PG Hash 索引：
  - 早期版本（< 10）有 bug，不推荐用
  - 10+ 修复，支持 WAL 复制
  - 只支持等值查询（=）
  - 比 B-tree 略快，但功能受限

CREATE INDEX idx_id ON t USING HASH(id);

3.7 PG 索引选型表

场景	索引类型
等值、范围、排序	B-tree（默认）
JSONB 查询、数组包含	GIN
地理、范围、模糊匹配	GiST
大表 + 时间范围扫描	BRIN
前缀匹配、路由	SP-GiST
仅等值 + 极致性能	Hash

四、Oracle 的索引特色

4.1 B-Tree Index（默认）

CREATE INDEX idx_name ON t(name);

-- Oracle 的 B-Tree 实际是 B+ 树
-- 叶子节点存：索引键 + rowid

4.2 Bitmap Index（位图索引）

适用：低基数列（如性别、状态、地区）
原理：每个 key 值对应一个位图，每一位代表一行

  表（5 行）：
  id | gender
  ---|-------
  1  | M
  2  | F
  3  | M
  4  | M
  5  | F

  Bitmap Index on gender:
    M → [1, 0, 1, 1, 0]
    F → [0, 1, 0, 0, 1]

查询 WHERE gender='M' AND region='East':
  M 位图 AND East 位图 → 一次位运算

CREATE BITMAP INDEX idx_gender ON users(gender);

-- 适合：低基数列 + 数据仓库（不频繁更新）
-- 灾难场景：高并发 OLTP 写入 → 锁整个位图段

4.3 Reverse Key Index（反向键索引）

解决"热块"问题：
  场景：主键是顺序 ID（1, 2, 3, ...），所有插入都打到 B+ 树最右侧叶子
       → 该页成为热块，并发插入互相阻塞

反向键索引：把 key 字节反转
  原 key: 12345 → 反向: 54321
  原 key: 12346 → 反向: 64321
  → 插入分散到 B+ 树不同叶子

代价：范围查询失效（不再连续）

`1`	`CREATE INDEX idx_id_reverse ON t(id) REVERSE;`

4.4 Function-Based Index

-- 经典场景：大小写不敏感查询
CREATE INDEX idx_lower_name ON t(LOWER(name));
SELECT * FROM t WHERE LOWER(name) = 'alice';  -- 走索引

-- 计算列
CREATE INDEX idx_amount_usd ON t(amount * 7.2);
SELECT * FROM t WHERE amount * 7.2 > 100;

4.5 Oracle 索引特色总览

索引类型	适用场景
B-Tree	通用
Bitmap	低基数列 + 数仓
Reverse	热块消除
Function-based	函数查询
IOT	索引组织表
Domain	用户自定义（如 Spatial）

五、联合索引与最左前缀

5.1 联合索引的结构

CREATE INDEX idx_a_b_c ON t(a, b, c);

-- B+ 树叶子节点按 (a, b, c) 排序：
-- (1, 1, 1) (1, 1, 2) (1, 2, 1) (1, 2, 3) (2, 1, 1) (2, 1, 5) ...

5.2 最左前缀原则

能用上 idx_a_b_c 的查询：
  WHERE a = 1                       ✅ 用 a
  WHERE a = 1 AND b = 2             ✅ 用 a, b
  WHERE a = 1 AND b = 2 AND c = 3   ✅ 用 a, b, c
  WHERE a = 1 AND c = 3             ✅ 用 a（c 用不上，跳过 b）
  WHERE a > 1 AND b = 2             ✅ 用 a（范围后断）
  WHERE b = 2                       ❌ 不用（缺最左 a）
  WHERE b = 2 AND c = 3             ❌ 不用
  WHERE a = 1 ORDER BY b, c         ✅ 用 a + 排序免费

5.3 为什么这样

B+ 树是有序的，按 (a, b, c) 排序：
  (1, 1, 1) < (1, 1, 2) < (1, 2, 1) < (2, 1, 1)

WHERE a = 1：从 (1, ?, ?) 段开始扫
WHERE a = 1 AND b = 2：进一步缩到 (1, 2, ?) 段
WHERE b = 2：B+ 树不是按 b 排序的，无法定位 → 退化为全索引扫描

5.4 范围查询"截断"后续列

WHERE a > 1 AND b = 2：
  a 是范围 → B+ 树定位到 a > 1 的范围，但 b 在这个范围内无序
  → 只能用 a，b 不能用索引

如何绕过：
  方案 1：调整索引列顺序（按"等值在前，范围在后"排）
  方案 2：把范围改成 IN 列表（a IN (2, 3, 4) AND b = 2）

5.5 设计建议

联合索引列顺序的优先级：
  1. 等值查询的列（最左）
  2. 排序列（中间，利用 B+ 树天然有序）
  3. 范围查询列（最右，避免截断）

反例：
  WHERE status = 'A' AND create_time > '2026-06-01'
  → idx(status, create_time)：先等值定位 status，再范围扫 create_time ✅
  → idx(create_time, status)：先范围扫 create_time，再过滤 status ❌（无效）

观察执行计划验证：
  MySQL: EXPLAIN SELECT ... → key_len 看用了几列
  PG: EXPLAIN (BUFFERS) SELECT ... → "Index Cond" 看用了哪些列
  Oracle: EXPLAIN PLAN → "Access Predicates" vs "Filter Predicates"
  SQL Server: SET SHOWPLAN_TEXT ON → Seek Predicate 是真用，Predicate 是过滤

六、覆盖索引、索引下推、条件下推

6.1 覆盖索引（Covering Index）

如果 SELECT 的所有列都在索引里 → 不需要回表

InnoDB 示例：
  CREATE INDEX idx_name_age ON users(name, age);
  SELECT name, age FROM users WHERE name = 'Alice';
  → 命中 idx_name_age，叶子节点存 (name, age, id)
  → 所有需要的列都在 → "Using index"（不回表）

-- MySQL 验证
EXPLAIN SELECT name, age FROM users WHERE name = 'Alice';
-- Extra: Using index → 覆盖索引生效

-- 故意触发回表
EXPLAIN SELECT name, age, email FROM users WHERE name = 'Alice';
-- Extra: <空> → 需要回表取 email

6.2 MySQL 的"覆盖"延伸：包含列

-- MySQL 8.0+
CREATE INDEX idx_name ON users(name) INVISIBLE;
ALTER TABLE users ADD INDEX idx_name_age_email (name) INCLUDE (age, email);
-- INCLUDE 列只放在叶子节点，不参与排序

-- Oracle / SQL Server / PG 都有类似 INCLUDE 子句

6.3 索引下推（Index Condition Pushdown, ICP）

MySQL 5.6+ 引入，针对联合索引：

  CREATE INDEX idx_a_b ON t(a, b);
  SELECT * FROM t WHERE a = 1 AND b LIKE '%abc%';

无 ICP（5.6 之前）：
  1. 走 idx_a_b 找到 a = 1 的所有行（比如 1000 行）
  2. 全部回表取整行
  3. 在 Server 层过滤 b LIKE '%abc%'
  → 1000 次回表

有 ICP：
  1. 走 idx_a_b 找到 a = 1 的所有行（1000 行）
  2. 在存储引擎层直接用 b LIKE '%abc%' 过滤（剩 10 行）
  3. 只回表 10 次
  → 减少 100 倍回表

1
2

EXPLAIN SELECT * FROM t WHERE a = 1 AND b LIKE '%abc%';
-- Extra: Using index condition → ICP 生效

6.4 条件下推到存储层

PG 和 Oracle 都有类似的下推机制：
  PG：把 WHERE 条件推到 Scan 节点（Index Scan 的 Index Cond）
  Oracle：谓词下推到 Table Access
  SQL Server：Seek Predicate（下推）vs Predicate（残留过滤）

判断方法：执行计划里"过滤发生得越早越好"

七、索引失效与"隐形索引"

7.1 索引失效的常见原因

1. 函数包装列
   WHERE LOWER(name) = 'alice'     -- 不走 idx_name
   → 解决：建函数索引 或 改写为 name = 'Alice' COLLATE ...

2. 隐式类型转换（经典坑）
   WHERE phone = 13800000000       -- phone 是 VARCHAR，传 INT
   → MySQL：函数 CAST(phone) → 不走索引
   → PG：报错（更严格）
   → 解决：传字符串 '13800000000'

3. LIKE 前缀通配
   WHERE name LIKE '%abc'          -- 不走索引
   WHERE name LIKE 'abc%'          -- 走索引
   → 解决：用全文索引（PG GIN / MySQL FULLTEXT）

4. OR 中部分列无索引
   WHERE a = 1 OR b = 2           -- 如果 b 没索引，整条不走索引
   → 解决：UNION ALL 或给 b 加索引

5. 计算 / 表达式
   WHERE id + 1 = 100              -- 不走索引
   → 改写为 WHERE id = 99

6. NULL 不被索引（部分数据库）
   Oracle：单列索引不存 NULL
   → 解决：建复合索引包含 NOT NULL 列

7.2 隐形索引（Invisible Index）

用途：临时禁用索引，观察是否真的没用，再决定删

MySQL 8.0+：
  ALTER TABLE t ALTER INDEX idx_name INVISIBLE;
  -- 优化器看不见 → 如果性能没变差 → 可以 DROP
  -- 如果变差 → 改回 VISIBLE

Oracle / PG（PG 12+ 也支持）都有类似机制

-- PG 用 ALTER INDEX ... ALTER COLUMN ... SET (attndims = 0) 不直接
-- 推荐用 extension：hypopg（虚拟索引，模拟）
CREATE EXTENSION hypopg;
SELECT * FROM hypopg_create_index('CREATE INDEX idx_test ON t(name)');
-- 不真建索引，只让优化器"以为"有 → 看 EXPLAIN 是否选择

7.3 索引选择性

索引值不值得建？看选择性：
  选择性 = 不同值的数量 / 总行数

  低选择性（< 0.1）：性别、状态、布尔 → 一般不建
  中选择性（0.1 ~ 0.5）：地区、年龄段 → 看场景
  高选择性（> 0.5）：用户 ID、订单号 → 必建

  PG：SELECT 1.0 * COUNT(DISTINCT col) / COUNT(*) FROM t;

八、索引维护代价

8.1 写入放大

每加一个索引，每次 INSERT 都多写一份：
  原表 + N 个索引 = N + 1 次写入

  UPDATE / DELETE 也要同步维护索引

经验值：
  - 一张表索引数建议 ≤ 5 个
  - 高写入表 ≤ 3 个
  - 数仓表（只读为主）可以多

8.2 页分裂与碎片

B+ 树插入时，如果目标页满了：
  → 把页分裂成两页，各放一半
  → 物理位置不连续，磁盘 I/O 变慢

  顺序插入（自增主键）：基本不分裂
  随机插入（UUID 主键）：频繁分裂

碎片化监控：
  MySQL: ANALYZE TABLE t; SHOW TABLE STATUS LIKE 't';
  PG: VACUUM (VERBOSE) t; 看 free space
  SQL Server: SELECT * FROM sys.dm_db_index_physical_stats(...)
  Oracle: ANALYZE INDEX idx VALIDATE STRUCTURE;

8.3 索引重建

-- MySQL（在线 DDL，8.0+）
ALTER TABLE t ENGINE=InnoDB;       -- 重建表（含所有索引）
ALTER TABLE t DROP INDEX idx, ADD INDEX idx (...);  -- 单独重建

-- PostgreSQL（CONCURRENTLY 不阻塞写）
REINDEX INDEX CONCURRENTLY idx_name;
REINDEX TABLE CONCURRENTLY t;

-- SQL Server
ALTER INDEX ALL ON t REBUILD;
ALTER INDEX ALL ON t REORGANIZE;   -- 轻量整理

-- Oracle
ALTER INDEX idx_name REBUILD ONLINE;

8.4 索引统计信息

优化器依赖统计信息决定走不走索引：
  行数、基数、最值、直方图

定期收集：
  MySQL: ANALYZE TABLE t;  （8.0 默认自动采样）
  PG: ANALYZE t;           （autovacuum 自动）
  Oracle: DBMS_STATS.GATHER_TABLE_STATS(...)
  SQL Server: UPDATE STATISTICS t;  （自动）

九、小结

本文学习了索引原理：

为什么 B+ 树是关系数据库的标准索引
聚集 vs 非聚集（Clustered vs Secondary）的术语差异
- InnoDB 主键即数据
- PG/Oracle/SQL Server 都是堆表 + 二级索引
PG 的索引武器库：B-tree / GIN / GiST / BRIN / SP-GiST / Hash
Oracle 的特色：Bitmap / Reverse / Function-based
联合索引的最左前缀原则与范围截断
覆盖索引、索引下推、条件下推
索引失效的六大原因与"隐形索引"调试法
索引维护的代价：写入放大、页分裂、统计信息

记住三句话：
  1. 关系数据库索引绝大多数是 B+ 树——因为磁盘 I/O 模型
  2. InnoDB 二级索引存"主键值"，PG/Oracle 存"行位置"——这是回表成本的根源
  3. 索引不是免费的——每加一个，写入代价线性增加

下一篇将进入事务主题：ACID 怎么实现？原子性靠 Undo，持久性靠 Redo，分布式事务怎么做？

数据库系列（二）：存储引擎 — 堆表 vs 索引组织表 vs 列存

Sun, 14 Jun 2026 16:00:00 +0800

写在前面

承接上一篇的"原理地图"，本文进入第一个子系统：存储引擎。我们要回答的核心问题是——

一行数据，在磁盘上到底长什么样？为什么 MySQL InnoDB 的主键就是数据，而 PostgreSQL 不是？

理解存储引擎是理解索引、事务、MVCC、日志所有后续主题的基础。本文横向对比 Oracle、SQL Server、MySQL（InnoDB）、PostgreSQL 四家的物理存储层。

一、数据在磁盘上长什么样

1.1 朴素模型：行 + 列

逻辑上一张表就是二维结构：

id  | name   | age | balance
----|--------|-----|--------
1   | Alice  | 28  | 1000
2   | Bob    | 35  | 2500
3   | Carol  | 22  | 800

但磁盘上不能直接放这个二维表，需要某种物理格式。所有关系数据库的答案都是同一个——把多行打包成一个固定大小的页（Page），页是磁盘 I/O 的最小单位。

1.2 为什么需要"页"

朴素方案：一行一行存
  - 一行 100 字节，磁盘扇区 4KB
  - 读一行实际读了 4KB（40 倍浪费）
  - 写一行也要刷 4KB

正确方案：把行打包成页（如 16KB 一个）
  - 一次 I/O 读 / 写一整页
  - 内部按行寻址（offset）
  - 缓冲池管理也是以页为单位
  - 局部性原理：相邻行经常一起访问

1.3 行存 vs 列存

页内部如何组织多行？有两种思路：

行存（Row-Based）：每一行连续存储
  [id1, name1, age1, bal1][id2, name2, age2, bal2]...
  适合：SELECT * FROM t WHERE id=1  （整行取出）
       UPDATE t SET age=age+1 WHERE id=1  （改一行）
  → OLTP 场景

列存（Columnar）：每一列连续存储
  id 列:  [1, 2, 3, ...]
  name 列: [Alice, Bob, Carol, ...]
  age 列: [28, 35, 22, ...]
  适合：SELECT AVG(age) FROM t  （只读 age 列）
       按列压缩率高（同质数据）
  → OLAP 场景

四大数据库默认都是行存，但 SQL Server / Oracle 都加了列存扩展用于 OLAP（详见第 5 节）。

二、物理存储单位对比

四家的命名不同，但层级结构惊人地一致：Block/Page → Extent → Segment → Tablespace。

2.1 层级结构总览

                       Tablespace（表空间）
                              │
                       Segment（段）
                       一个表 / 索引 = 一个或多个段
                              │
                       Extent（区）
                       连续多个 Page 组成
                              │
                       Page / Block（页 / 块）
                       磁盘 I/O 最小单位
                              │
                       Row / Tuple（行 / 元组）
                       实际的数据

2.2 各家的实际大小

层级	Oracle	SQL Server	MySQL InnoDB	PostgreSQL
Page/Block	2K/4K/8K/16K（默认 8K）	8K	16K（可配 4K/8K）	8K（编译时定）
Extent	64K（8 个 block）	64K（8 页）	1M（64 页）	——（无明确区）
Segment	表 / 索引一个段	表 / 索引	表 / 索引（每表一个段）	——（PG 用文件直接管理）
Tablespace	系统 / 用户 / Undo	系统 / 用户	系统 / file-per-table	pg_default / pg_global
行内最大长度	块大小限制（4K）	8K（行不能跨页）	½ 页（约 8K，可溢出）	2GB（TOAST 拆分）

2.3 Oracle 的 Block 结构

一个 8KB Oracle Block 内部：

  ┌─────────────────────────────┐
  │   Block Header（块头）       │  ~100 字节
  │   - 类型（data/index/undo）  │
  │   - SCN、事务槽 (ITL)       │
  ├─────────────────────────────┤
  │   Row Directory（行目录）    │  每行 2~4 字节偏移
  │   指向下面的行实际位置         │
  ├─────────────────────────────┤
  │   Free Space（空闲区）        │  从中间向两边生长
  ├─────────────────────────────┤
  │   Row Data（行数据）          │  实际行 + 列值
  └─────────────────────────────┘

关键：ITL（Interested Transaction List）
  - 每个被修改的 block 记录涉及的事务
  - 是 Oracle MVCC 实现的关键（详见第 5 篇）

2.4 MySQL InnoDB 的 Page 结构

一个 16KB InnoDB Page 内部：

  ┌─────────────────────────────┐
  │  File Header（38B）          │
  │  - 页号、表空间、前后页指针    │
  ├─────────────────────────────┤
  │  Page Header（56B）          │
  │  - 索引 ID、记录数、空闲指针   │
  ├─────────────────────────────┤
  │  Infimum + Supremum Records │  系统伪行（最小/最大）
  ├─────────────────────────────┤
  │  User Records                │  实际行记录
  │  （从下往上增长）              │
  ├─────────────────────────────┤
  │  Free Space                  │
  ├─────────────────────────────┤
  │  Page Directory（槽位）       │  二分查找索引
  ├─────────────────────────────┤
  │  File Trailer（8B）          │  校验和、LSN
  └─────────────────────────────┘

每行结构（COMPACT 格式）：
  [变长字段长度][NULL 位图][记录头][事务ID][回滚指针][列1][列2]...
                                   ↑          ↑
                              DB_TRX_ID   DB_ROLL_PTR
                              （用于 MVCC，详见第 5 篇）

2.5 PostgreSQL 的 Page 结构

一个 8KB PostgreSQL Page：

  ┌─────────────────────────────┐
  │  Page Header（24B）          │
  │  - LSN、校验和、行数          │
  ├─────────────────────────────┤
  │  ItemId Array（行指针）       │  4B/项
  ├─────────────────────────────┤
  │  Free Space                  │
  ├─────────────────────────────┤
  │  Tuples（实际行）             │
  │  （从下往上生长）              │
  └─────────────────────────────┘

每个 Tuple 头（23B 起）：
  [xmin][xmax][cid][ctid][infomask][...][columns]
   ↑     ↑                ↑
  创建  删除/更新         当前物理位置（用于 HOT 更新）
  事务  事务

观察：
  - 三家结构非常相似：Header + Directory + Free + Data
  - InnoDB / PG 都把事务信息（MVCC）直接放在行头
  - Oracle 用独立的 ITL 槽（块级别）记录事务
  - PG 8KB 是写死的（编译时定），其他三家可配

2.6 临时表的存储

数据库	临时对象存放	特点
Oracle	Temporary Tablespace	每会话独立段，自动回收
SQL Server	TempDB	系统级共享库，承载所有临时对象 + 排序
MySQL	临时表空间（ibtmp1）	全局共享 + 会话临时表空间（8.0+）
PostgreSQL	`pg_default` 或专用表空间	默认在 base/ 目录

关键差异：
  - SQL Server 用 TempDB 统一承载，是性能调优重点
  - MySQL 8.0 之前临时表都在 ibdata1，导致系统表空间膨胀
  - PG 临时表和普通表共用存储，但通过 relpersistence 区分

三、堆表 vs 索引组织表

这是四大数据库最本质的差异之一：一张表的数据，是按"主键有序"存放，还是无序堆放？

3.1 两种组织方式

堆表（HEAP）：
  数据行无序堆放在数据页中
  主键只是"另一个二级索引"
  索引指向行的物理位置（rowid / ctid / RID）

  ┌────────┐         ┌──────────────────┐
  │ 主键索引 │ ──────→│ Heap Page         │
  │ B+树    │         │ [row3][row1][row2]│  ← 无序
  └────────┘         └──────────────────┘

  特点：
  - 主键索引和数据分离
  - 主键查询要"两次 B+ 树查找"（先找索引，再读数据页）
  - 二级索引可以指向 rowid（短）
  - 代表：PostgreSQL、Oracle（默认）、SQL Server（默认）

索引组织表（IOT / Clustered Table）：
  数据行直接按主键有序存放在 B+ 树的叶子节点
  "主键索引就是数据本身"

       主键 B+ 树（叶子就是数据）
              │
              ▼
  ┌─────────────────────────────┐
  │ [PK=1, row1][PK=2, row2]... │  ← 主键有序
  └─────────────────────────────┘

  特点：
  - 没有独立的"堆"，整张表就是一棵 B+ 树
  - 主键查询只需走一棵树
  - 二级索引指向主键值（长，且需要二次查找）
  - 代表：MySQL InnoDB、SQL Server（Clustered）、Oracle IOT

3.2 四家的实际选择

数据库	默认组织方式	可选 IOT？
Oracle	堆表（默认）	✅ IOT 显式声明
SQL Server	堆表（无主键时）/ Clustered（有主键时）	✅ Clustered Index
MySQL InnoDB	强制 IOT	❌ 没有"堆"概念
PostgreSQL	堆表（唯一选项，12+ 抽象了 TAM 接口）	❌

3.3 深入 MySQL InnoDB：为什么主键即数据

InnoDB 中：
  - 每张表 = 一棵按主键排序的 B+ 树（Clustered Index）
  - 这棵树的叶子节点直接存"完整行"
  - 主键之外的索引叫 Secondary Index，叶子节点存的是"主键值"

  表 accounts(id PK, name, balance):

  Clustered Index (按 id):
                       [10│20]               ← 内部节点
                      /       \
              [1│2│...10]   [11│...│20]      ← 叶子 = 整行数据
              ↓               ↓
              id=1 的完整行   id=11 的完整行

  Secondary Index (name):
              [Alice│Bob]                ← 内部节点
              /         \
        [Alice→1][Bob→2]   [Carol→3]     ← 叶子 = name + 主键值
                                       （查到主键后，回 Clustered 树再查一次）

-- 一次查询，两种索引路径差异
SELECT balance FROM accounts WHERE id = 1;
-- 直接走 Clustered 树，1 次 I/O

SELECT balance FROM accounts WHERE name = 'Alice';
-- 走 Secondary 树找到主键 id=1 → 回 Clustered 树找到 balance → 2 次 I/O（"回表"）

3.4 深入 PostgreSQL：堆表 + ctid

PostgreSQL 中：
  - 表数据存在 Heap（堆）中，无序
  - 所有索引（包括主键）都是"二级索引"
  - 索引指向 ctid（物理位置：页号 + 行偏移）

  Heap File:
  Page 0:  [row(id=1)][row(id=3)][row(id=2)]   ← 任意顺序
  Page 1:  [row(id=5)][row(id=4)][row(id=6)]

  Primary Key Index (id):
              [2│4│6]
              /   |   \
      [1→(0,1)] [2→(0,3)] [3→(0,2)]
                  叶子 = id + ctid

-- 看看实际的 ctid
SELECT ctid, id, name FROM accounts;
-- ctid   id  name
-- (0,1)  1   Alice
-- (0,2)  3   Carol
-- (0,3)  2   Bob
-- 物理顺序 ≠ 主键顺序

-- 主键查询也要两步：索引找 ctid → heap 取数据
SELECT balance FROM accounts WHERE id = 1;
-- 走 PK 索引找到 ctid=(0,1) → 回 heap 读 → 2 次 I/O

3.5 两种模型的性能权衡

维度	IOT（InnoDB/MSSQL Clustered）	HEAP（PG/Oracle 默认）
主键查询	快（一棵树）	慢（两次查找）
二级索引查询	慢（需要回主键树）	快（直接到 heap）
范围查询（按主键）	快（叶子有序连续）	慢（需要排序）
插入	主键有序时慢（B+ 树页分裂）	快（追加到堆末尾）
二级索引大小	大（存主键值）	小（存 ctid/rowid）
二级索引重建（改主键时）	极慢（所有二级索引都要改）	快（指向物理位置，不变）

实战含义：
  - InnoDB 中改主键 = 灾难（所有二级索引失效重建）
    → 所以 InnoDB 主键推荐：自增 BIGINT，永不变
  - PG 中改主键 = 改个约束（索引重建，但 heap 不动）
    → PG 改主键代价相对小

  - InnoDB 二级索引查询性能 < PG（需要"回主键树"）
  - 但 InnoDB 主键范围查询（按时间、按 ID 范围）> PG

这就是为什么 MySQL 表设计强调"主键设计"，PG 强调"索引设计"。

四、缓冲池

修改的是内存中的页，不是磁盘上的页。这块内存就叫"缓冲池"（Buffer Pool）。

4.1 缓冲池的作用

没有缓冲池：
  读：每次 SELECT 都从磁盘读页 → 极慢
  写：每次 UPDATE 都直接刷盘 → 极慢 + 磁盘磨损

有缓冲池：
  读：先查 Buffer Pool，命中直接返回；未命中则从磁盘读入
  写：直接改 Buffer Pool 中的页（变成"脏页" dirty page）
       后台异步刷盘（详见第 7 篇 Checkpoint）

4.2 替换算法：LRU 与冷热分离

朴素 LRU 的问题：一次全表扫描会把热点页全冲掉（“缓存污染”）。所以四大数据库都对 LRU 做了改进。

改进版 LRU（中点插入策略）：
  把 LRU 链分成两段：

  [Old sublist（冷区）] | [New sublist（热区）]
              ↑                   ↑
           midpoint           midpoint move threshold
              ↑
       新读入的页插这里
       （而不是直接进热区）

  真正热的数据：在冷区停留超过 innodb_old_blocks_time（默认 1 秒）
                才会被推入热区
  → 全表扫描的页只会短暂留在冷区，被快速淘汰，不会冲掉热区

4.3 四家的实现

数据库	缓冲池名称	冷热分离	多实例	后台写
Oracle	Buffer Cache	✅（KEEP/RECYCLE/DEFAULT 池）	✅（多池）	DBWn
SQL Server	Buffer Pool	✅（Just-In-Time）	单一池	Checkpoint / Lazy Writer
MySQL InnoDB	Buffer Pool	✅（young/old sublist）	✅（多 instance）	Page Cleaner Thread
PostgreSQL	Shared Buffers	✅（环形缓冲区）	单一池	bgwriter / checkpointer

4.4 关键参数

-- Oracle
ALTER SYSTEM SET db_cache_size = 8G;  -- Buffer Cache 大小
ALTER SYSTEM SET db_keep_cache_size = 1G;  -- 热点小表保留

-- SQL Server
-- "max server memory" 控制整个 Buffer Pool 上限
EXEC sp_configure 'max server memory (MB)', 16384;
RECONFIGURE;

-- MySQL
[mysqld]
innodb_buffer_pool_size = 8G       -- 最重要参数，建议物理内存 60~70%
innodb_buffer_pool_instances = 8   -- 多实例，减少锁竞争
innodb_old_blocks_time = 1000      -- 冷区停留时间（ms）

-- PostgreSQL
shared_buffers = 2GB               -- 推荐 25% 物理内存
effective_cache_size = 8GB         -- 仅给优化器参考，不实际分配

调优经验：
  - MySQL：innodb_buffer_pool_size 是 OLTP 性能第一参数，通常设为物理内存 70%
  - PostgreSQL：shared_buffers 一般不超过物理内存 25%（PG 还要用 OS page cache）
  - SQL Server：max server memory 通常留 4~8GB 给 OS
  - Oracle：SGA（含 Buffer Cache）+ PGA 总和 ≈ 物理内存 80%

五、列存扩展

行存适合 OLTP，列存适合 OLAP。四大数据库都做了列存扩展来支持分析查询。

5.1 SQL Server Columnstore

SQL Server 2012+ 引入 Columnstore Index：
  - 一张表可以有 Columnstore Index（聚集或非聚集）
  - 行组（Rowgroup）：每 100 万行为一组，按列编码存储
  - 列段（Column Segment）：每个列段存储一组数据
  - 配合 Batch Mode 执行（向量化）

CREATE CLUSTERED COLUMNSTORE INDEX cci ON big_table;
-- 整表变成列存

CREATE NONCLUSTERED COLUMNSTORE INDEX ncci ON big_table(col1, col2);
-- 局部列存（2014+）

5.2 Oracle In-Memory

Oracle 12.1.0.2+ 引入 In-Memory Column Store（IMCS）：
  - 数据在 SGA 中以"行存 + 列存"双格式存储
  - 列存叫 In-Memory Compression Unit（IMCU）
  - OLTP 走行存（Buffer Cache），OLAP 走列存（IMCS）

ALTER TABLE big_table INMEMORY;
-- 该表的列被加载到 IMCS

特点：
  - 行/列双写：内存占用大
  - 透明：优化器自动选择
  - 商业版高级特性

5.3 PostgreSQL 的列存方案

PG 本身没有内置列存，但有方案：

1. cstore_fdw（早期，Citus 出品）
   - 用 FDW（Foreign Data Wrapper）实现
   - 已基本停更

2. Citus（已并入 PG 生态）
   - 列式压缩 + 分布式

3. TimescaleDB（时序场景）
   - 时序数据自动按时间分区 + 压缩

4. Greenplum（PG 分支）
   - MPP 数据库，原生列存支持

5.4 MySQL 的列存现状

MySQL 8.x 没有列存。
- HeatWave（MySQL Cloud 在 OCI 上的扩展）有列存加速
- 但开源 MySQL 没有列存
- 分析查询需要走 OLAP 引擎（如外接 Doris / ClickHouse）

5.5 行存 vs 列存选型

场景	推荐
高并发 OLTP（按主键点查 / 范围更新）	行存（默认）
多维聚合分析（GROUP BY 多列、SUM/AVG）	列存
混合负载（HTAP）	行存为主 + 列存索引 / IMCS
大宽表 + 高压缩比	列存

六、内置存储引擎矩阵

6.1 MySQL：可插拔引擎之王

SHOW ENGINES;

-- 主要引擎：
-- InnoDB     默认，事务、行锁、MVCC
-- MyISAM     老引擎，表锁，崩溃恢复弱
-- Memory     内存表，重启丢失
-- Archive    高压缩归档，只支持插入
-- NDB        分布式集群（MySQL Cluster）
-- Blackhole  什么都不存（用于复制中转）
-- 第三方：RocksDB（MyRocks）、TokuDB、TiDB

设计：
  每张表可以选不同引擎
  CREATE TABLE orders (...) ENGINE=InnoDB;
  CREATE TABLE logs (...) ENGINE=Archive;

6.2 Oracle：段类型 + 表压缩

Oracle 不是"多引擎"，而是统一引擎 + 多种段类型：

  段类型：
  - Heap Table（默认堆表）
  - Index-Organized Table（IOT，索引组织表）
  - Partitioned Table（分区表）
  - Cluster Table（聚簇表）
  - External Table（外部表，HDFS 文件等）

  压缩选项：
  - OLTP Table Compression
  - Advanced Compression
  - Hybrid Columnar Compression（HCC，Exadata 专属）

6.3 SQL Server：堆表 vs Clustered

SQL Server 一张表的状态：
  - 堆表（Heap）：没有 Clustered Index
  - Clustered Table：有 Clustered Index（按主键组织）

  CREATE TABLE t (id INT PRIMARY KEY, ...);
  -- PRIMARY KEY 隐式创建 Clustered Index → 表变成 Clustered

  ALTER TABLE t DROP CONSTRAINT pk_t;
  -- 删主键后，表变回 Heap

内存优化表（In-Memory OLTP）：
  - SQL Server 2014+ 引入
  - 完全在内存中，无锁（用 MVCC）
  - 用于极高性能 OLTP

6.4 PostgreSQL：Table Access Method 抽象

PG 12 引入 Table Access Method (TAM) 抽象：
  - 12 之前：所有表都是 Heap
  - 12+：可以插件化实现新表类型
  - 目前主流还是 heap TAM

  扩展：
  - zheap（PG 社区研发，目标减少表膨胀，未发布）
  - 其他自定义 TAM

七、性能影响

7.1 为什么 OLTP 必须行存

OLTP 工作负载特征：
  - 大量短事务
  - 按主键 / 索引点查
  - 修改单行多列（UPDATE）

OLAP 工作负载特征：
  - 少量长查询
  - 大范围扫描
  - 按列聚合（GROUP BY + SUM/AVG）

行存优势（OLTP）：
  - 一次 I/O 读出整行（修改单行多列只需 1 次页 I/O）
  - 局部性好（同时访问同一行的多列）
  - 事务实现简单（锁单行）

7.2 表设计原则

InnoDB 表设计：
  1. 必须有主键（推荐 BIGINT AUTO_INCREMENT）
     → 没有 PK 的话会选唯一键，再没有就生成隐藏 6 字节 ROW_ID
  2. 主键尽量短（让二级索引小）
  3. 主键不要变更（否则所有二级索引重建）
  4. 主键单调递增（减少 B+ 树页分裂）

PostgreSQL 表设计：
  1. 主键选 UUID 或 SERIAL/BIGSERIAL 都行（不影响 heap）
  2. 关键在索引设计
  3. 注意 fillfactor（默认 100，频繁更新降到 80~90 留 HOT 空间）

SQL Server 表设计：
  1. 选择 Clustered Index 列（默认主键）
  2. Clustered 列要短、单调、不变
  3. 大表考虑分区 + Columnstore 索引（混合）

Oracle 表设计：
  1. 默认 Heap Table，分析场景考虑 IOT 或分区表
  2. 用 Sequence 而非 AUTO（Oracle 12c+ 才有 IDENTITY）
  3. HCC 压缩用于 Exadata 上的数仓

7.3 常见性能陷阱

1. MySQL InnoDB：UUID 主键
   问题：UUID 无序 → B+ 树频繁页分裂 → 插入性能差 + 索引膨胀
   方案：用 BIGINT AUTO_INCREMENT 或有序 UUID

2. PostgreSQL：高更新场景
   问题：MVCC 写新 tuple + 旧 tuple 不删 → 表膨胀
   方案：autovacuum 配置、fillfactor 降低、pg_repack 重整

3. SQL Server：Clustered Index 选错
   问题：用 GUID 当 Clustered Key → 页分裂 + 缓存碎片
   方案：Clustered 用 IDENTITY INT/BIGINT，GUID 用 ROWGUIDCOL + NonClustered

4. Oracle：HCC 压缩误用
   问题：在 OLTP 表上用 HCC → 锁升级 + 性能崩溃
   方案：HCC 仅用于只读 / 批量加载场景

八、小结

本文学习了存储引擎的核心原理：

物理存储层级：Tablespace → Segment → Extent → Page → Row
四家的页大小：Oracle 8K / MSSQL 8K / InnoDB 16K / PG 8K
行存 vs 列存：OLTP 用行存，OLAP 用列存
堆表 vs 索引组织表（IOT）：本质差异
- InnoDB 强制 IOT，主键就是数据
- PG/Oracle 默认堆表，所有索引都是二级
- SQL Server 由是否 Clustered 决定
缓冲池：LRU 冷热分离避免缓存污染
列存扩展：MSSQL Columnstore / Oracle IMCS / PG 第三方
各家内置存储引擎矩阵

记住三句话：
  1. 物理存储 = 页为单位的 B+ 树 / 堆文件
  2. InnoDB 主键就是数据，PG 主键只是另一个索引
  3. 修改是先改内存页，后台异步刷盘（这就是"事务持久性"实现的基础）

下一篇将深入索引原理：为什么几乎所有索引都是 B+ 树？PG 的 GIN/GiST 是什么？为什么联合索引要最左前缀？

数据库系列（一）：从一行 UPDATE 看懂关系数据库

Sun, 14 Jun 2026 15:00:00 +0800

写在前面

本文是数据库系列的第一篇。这个系列计划写 10 篇，主线是横向对比 Oracle、SQL Server、MySQL、PostgreSQL 四大关系数据库的底层原理，并在最后跳出来俯瞰整个数据存储生态（OLAP / 数仓 / Lakehouse）。

开篇不深入任何单一原理，目标是建立一张"原理地图"——用一行 UPDATE 语句把整本系列的 10 个主题串起来，让你看后面每一篇时都知道它处在地图的哪一格。

一、从一行 UPDATE 说起

考虑这条最普通的 SQL：

`1`	`UPDATE accounts SET balance = balance - 100 WHERE id = 42;`

在你按下回车到返回"1 row affected"之间，数据库内部发生的事情远比你想象的多：

1. 连接层：    校验会话、权限、参数绑定
2. 解析器：    词法/语法分析，生成 AST
3. 优化器：    决定走哪个索引、用什么 JOIN 顺序
4. 执行器：    按"打开表 → 定位行 → 改字段"的步骤执行
5. 事务层：    写 Undo Log（保证可回滚）+ 写 Redo Log（保证持久）
6. 缓冲池：    修改的是内存中的页，并不立即落盘
7. 锁系统：    对 id=42 这行加 X 锁，避免其他事务改
8. MVCC：      旧版本写入 Undo 链，让并发读不会看到新值
9. 提交：      Redo Log fsync 到磁盘，事务正式可见
10. 复制：     Redo/WAL 流式推送给从库（如果是主从架构）

后续：
  - 后台 Checkpoint 把脏页刷盘
  - 崩溃重启时用 Redo 重放、Undo 回滚
  - Binlog 也会被消费同步到下游（订阅 / 数仓）

这一行 SQL 牵出了 10 个原理子系统，正是本系列要逐个深挖的：

步骤	涉及子系统	本系列对应篇
4-5	存储引擎（数据怎么放、页怎么组织）	第 2 篇
3,4	索引（怎么定位 id=42 这行）	第 3 篇
5,9	事务 ACID（原子性 + 持久性）	第 4 篇
8	MVCC 与隔离级别	第 5 篇
7	锁与并发控制	第 6 篇
5,9	日志与崩溃恢复	第 7 篇
10	复制与高可用	第 8 篇
2,3	SQL 方言与查询优化器	第 9 篇
——	数据存储全景（OLAP/数仓/Lakehouse）	第 10 篇

读完这 10 篇，再回头看这行 UPDATE，你应当能说清每一步在四大数据库里叫什么名字、走什么代码路径、踩到哪些坑。

二、四大关系数据库的身世

2.1 Oracle：商业数据库的标杆

出身：1979 年由 Larry Ellison 创立，关系数据库商业化的先驱
版本：Oracle 7 → 8i → 9i → 10g → 11g → 12c → 18c → 19c → 21c → 23ai
定位：企业级核心交易系统、大型 OLTP、数据仓库
关键词：SGA/PGA、RAC（共享存储集群）、Data Guard、ASM、Exadata 一体机
许可证：商业，按 CPU 插槽计费，昂贵

2.2 SQL Server：微软生态的深度集成

出身：1989 年微软与 Sybase 合作开发，后独立分叉
版本：6.5 → 7.0 → 2000 → 2005 → ... → 2019 → 2022
定位：Windows 生态首选、企业 OLTP、近年也做 Linux + 容器
关键词：T-SQL、SQLOS、AlwaysOn、MSDTC、Columnstore、SSIS/SSAS/SSRS
许可证：商业，按 Core 计费，Express 免费但有限制

2.3 MySQL：互联网公司的最爱

出身：1995 年瑞典 MySQL AB 公司，2008 被 Sun 收购，2010 被 Oracle 收购
版本：3.x → 4.x → 5.x → 8.0 → 8.4 → 9.x（创新版）
分支：MariaDB（MySQL 创始人 fork）、Percona Server（性能版）
定位：互联网 OLTP、Web 应用、电商
关键词：InnoDB（默认引擎）、Binlog、MGR（Group Replication）、半同步复制
许可证：GPL + 商业双授权

2.4 PostgreSQL：最像 Oracle 的开源数据库

出身：1996 年从 Berkeley 的 POSTGRES 项目演化而来，2010 后社区爆发
版本：9.x → 10 → 11 → ... → 17
定位：复杂查询、地理数据（PostGIS）、JSON、扩展生态
关键词：进程模型、WAL、流复制 + 逻辑复制、丰富的索引类型、扩展（Extension）
许可证：PostgreSQL License（BSD-like），完全开源

2.5 四家定位坐标

                       OLAP 能力 ↑
                              │
              Oracle   ───────┼────────  PostgreSQL
                              │
                SQL Server    │
                              │
            ──────────────────┼──────────────  成熟度 →
                              │
                     MySQL    │
                              │
                       OLTP 能力 ↑（其实是同一轴）

不同象限的擅长领域：
  - Oracle/SQL Server：金融核心、ERP、关键交易系统
  - MySQL：互联网高并发 OLTP
  - PostgreSQL：复杂分析、地理数据、JSON 存储

三、进程/线程模型对比

四大数据库的"骨架"——也就是它们如何组织进程/线程——差异巨大。这个差异决定了内存架构、连接方式、并发性能的根本走向。

3.1 Oracle：多进程 + 共享内存（SGA）

一个 Oracle 实例由多个进程组成，进程间通过共享内存段（SGA）通信：

  ┌──────────────────────────────────────┐
  │              SGA（共享内存）            │
  │  Buffer Cache / Redo Buffer /        │
  │  Shared Pool / Large Pool / Java Pool│
  └────┬──────┬──────┬──────┬──────┬─────┘
       │      │      │      │      │
     PMON  SMON   DBWn  LGWR  CKPT  ...（后台进程）
              ▲
              │
       Server Process（每个会话一个，或共享）

特点：
  - 后台进程分工：DBWn 写脏页、LGWR 写 Redo、SMON 系统监控、PMON 进程监控
  - 两种连接模式：
    * Dedicated Server：每个会话一个 server 进程（默认）
    * Shared Server：通过 dispatcher 共享，适合大量短连接
  - 进程间通过共享内存（SGA）高效通信，无 IPC 开销

3.2 SQL Server：单进程多线程（SQLOS）

SQL Server 是一个进程，里面跑数千个线程，由 SQLOS（调度器）管理：

  ┌──────────────────────────────────────┐
  │         sqlservr.exe（单进程）         │
  │  ┌─────────────────────────────┐     │
  │  │           SQLOS              │     │
  │  │  Scheduler（每 CPU 一个）     │     │
  │  └────────┬────────┬────────┬───┘     │
  │           │        │        │         │
  │       Worker   Worker   Worker        │
  │      (线程)   (线程)   (线程)          │
  └──────────────────────────────────────┘
                 │
              Buffer Pool（用户态内存）

特点：
  - 单进程多线程，所有连接共用一个进程
  - SQLOS：自研的用户态调度器，避免 OS 上下文切换
  - 每个 CPU 一个 Scheduler，Worker 跑在上面
  - 内存：Buffer Pool 是用户态分配，不需要共享内存段
  - 线程切换比进程切换便宜，适合极高并发

3.3 MySQL：多线程（每个连接一个线程）

MySQL 服务器进程是单进程多线程，类似 SQL Server：

  ┌──────────────────────────────────────┐
  │         mysqld（单进程）                │
  │  ┌────────────────────┐               │
  │  │  Server Layer       │               │
  │  │  （解析/优化/执行）   │               │
  │  └─────────┬──────────┘               │
  │            │                          │
  │      ┌─────┴───────┐                  │
  │      ▼             ▼                  │
  │   InnoDB        其他引擎               │
  │   （独立线程池）                        │
  └──────────────────────────────────────┘

线程类型：
  - connection thread：每个客户端连接一个
  - innodb master thread：刷盘、合并
  - purge thread：清理 Undo
  - page cleaner thread：刷脏页
  - IO thread：AIO 读写

特点：
  - Server Layer + Storage Engine 双层架构（引擎可插拔）
  - 默认每个连接一个线程（thread-per-connection）
  - 5.5+ 支持 thread pool（企业版 / Percona / MariaDB）
  - InnoDB 内部有独立的线程池负责后台任务

3.4 PostgreSQL：多进程（每个连接一个进程）

PostgreSQL 是最传统的"多进程"架构：

  ┌──────────────────────────────────────┐
  │            postmaster（主进程）         │
  │  fork                                │
  │   ├── backend（连接 1）                │
  │   ├── backend（连接 2）                │
  │   └── backend（连接 3）                │
  │                                       │
  │  + 后台进程：                          │
  │    checkpointer、bgwriter、walwriter │
  │    autovacuum、stats collector        │
  └──────────────────────────────────────┘
         │
      Shared Buffers（共享内存段，System V / POSIX shm）

特点：
  - 每个连接 fork 一个 backend 进程（进程模型）
  - 进程间通过共享内存通信（Shared Buffers）
  - 类似 Oracle，但更"原始"：没有 dispatcher 模式
  - 优点：进程隔离好，崩溃不影响其他连接
  - 缺点：进程比线程重，大量连接时内存开销大
  - 连接池方案：pgbouncer / pgcat（在客户端和数据库之间）

3.5 横向对比表

维度	Oracle	SQL Server	MySQL	PostgreSQL
进程/线程	多进程	多线程（SQLOS）	多线程	多进程
共享内存	SGA	Buffer Pool（用户态）	Buffer Pool（用户态）	Shared Buffers
连接模型	Dedicated/Shared	Thread pool	Thread-per-conn	Process-per-conn
后台任务	DBWn/LGWR/SMON	后台线程	Master/Purge/Cleaner	bgwriter/walwriter
大量连接方案	Shared Server	默认就支持	企业版线程池	pgbouncer

关键差异：
  - Oracle/PG：操作系统级进程，崩溃影响小但开销大
  - MSSQL/MySQL：用户态线程，开销小但单线程 bug 会拖垮整个实例
  - PG 是四家里连接模型最"重"的，所以 pgbouncer 几乎是生产标配

四、整体架构

抛开进程/线程细节，关系数据库的逻辑架构大体是相似的：

        ┌──────────────────────────────────────┐
        │            客户端 / Driver              │
        └─────────────────┬────────────────────┘
                          │ SQL（TDS/MySQL/Wire/Net8 协议）
                          ▼
        ┌──────────────────────────────────────┐
        │             连接层                     │
        │   鉴权 / 会话 / 进程或线程分配           │
        └─────────────────┬────────────────────┘
                          ▼
        ┌──────────────────────────────────────┐
        │             解析器 Parser              │
        │   SQL 文本 → AST 语法树                 │
        └─────────────────┬────────────────────┘
                          ▼
        ┌──────────────────────────────────────┐
        │             优化器 Optimizer           │
        │   AST → 执行计划（RBO / CBO）           │
        └─────────────────┬────────────────────┘
                          ▼
        ┌──────────────────────────────────────┐
        │             执行器 Executor            │
        │   算子：Scan/Filter/Join/Agg/Sort    │
        └─────────────────┬────────────────────┘
                          ▼
        ┌──────────────────────────────────────┐
        │          存储引擎 Storage Engine       │
        │   页/块读写、缓冲池、索引、事务、日志    │
        └─────────────────┬────────────────────┘
                          ▼
                    磁盘 / SSD

4.1 MySQL 的特殊之处：可插拔存储引擎

Server Layer（解析/优化/执行）和 Storage Engine 是分离的：

  Server Layer
  ├── InnoDB   ← 默认，事务、行锁、MVCC
  ├── MyISAM   ← 老引擎，表锁，已不推荐
  ├── Memory   ← 内存表
  ├── Archive  ← 压缩归档
  ├── NDB      ← 集群（MySQL Cluster）
  └── 第三方：RocksDB、TokuDB、TiDB（兼容协议）

其他三家：
  - Oracle：可换段类型（heap / index-organized / partitioned），但引擎统一
  - SQL Server：可换页压缩、列存索引，但引擎统一
  - PostgreSQL：12+ 有 Table Access Method 抽象，目前主要是 heap

MySQL 这种设计的好处和代价：

好处：可以针对场景选引擎（OLTP 用 InnoDB，归档用 Archive）
代价：跨引擎功能不统一（MyISAM 不支持事务、InnoDB 才有外键等）

4.2 解析器与优化器

数据库	解析器	优化器	执行器
Oracle	自研	CBO + RBO	Row-based + Vectorized（12c+）
SQL Server	自研	CBO（Cost-Based）	Row + Batch mode
MySQL	自研（8.0+ 重大重写）	CBO（5.7+ 完善）	Iterator + Volcano
PostgreSQL	自研（基于 flex/bison）	CBO + Genetic（GEQO）	Volcano model

后续第 9 篇会深入展开优化器对比，这里先建立"解析器 → 优化器 → 执行器"的概念骨架。

五、本系列 10 篇要解决的 10 个问题

把 10 篇的目标用一句话讲清楚：

篇	主题	一句话问题
1（本篇）	开篇总览	关系数据库内部到底有几个子系统？
2	存储引擎	一行数据在磁盘上长什么样？为什么 MySQL 主键就是数据？
3	索引原理	为什么几乎所有索引都是 B+ 树？PG 的 GIN/GiST 又是什么？
4	事务 ACID	原子性怎么实现？Durability 怎么保证？分布式事务怎么落？
5	MVCC 与隔离级别	为什么读不阻塞写？为什么 PostgreSQL 表会膨胀？
6	锁与并发控制	行锁怎么实现？SQL Server 为什么会锁升级？死锁怎么破？
7	日志与崩溃恢复	Redo、Undo、Binlog、WAL 这么多日志都是干嘛的？
8	复制与高可用	主从怎么同步？脑裂怎么防？RAC、MGR、AlwaysON 各是什么？
9	SQL 方言与优化器	同样的 SQL 为什么在 PG 比 MySQL 快 10 倍？
10	数据存储全景	OLTP、OLAP、HTAP、数仓、Lakehouse 怎么选？

每篇都会包含三个层次：

原理：核心机制 + 算法 + 数据结构
对比：四家差异 + 命名对照 + 优劣
实战：执行计划、配置参数、踩坑案例

六、核心术语对照表

四大数据库的术语往往表达同一个概念，但叫法完全不同。这张表是后续阅读的"翻译字典"。

6.1 内存相关

概念	Oracle	SQL Server	MySQL (InnoDB)	PostgreSQL
数据缓存	Buffer Cache	Buffer Pool	Buffer Pool	Shared Buffers
日志缓存	Redo Log Buffer	Log Cache	Redo Log Buffer	WAL Buffers
共享内存区	SGA	——（用户态分配）	——（用户态分配）	Shared Memory
私有内存	PGA	——	Thread stack	Process Mem
SQL/计划缓存	Shared Pool (Library Cache)	Plan Cache	Query Cache（已废弃）	plpgsql cache

6.2 后台任务

任务	Oracle	SQL Server	MySQL	PostgreSQL
写脏页	DBWn	Checkpoint/Lazy Writer	Page Cleaner	bgwriter / checkpointer
写日志	LGWR	Log Writer	Log Manager	walwriter
清理旧版本	SMON（Undo 表空间）	——（tempdb 清理）	Purge Thread	autovacuum
统计信息收集	自动（GATHER_STATS_JOB）	自动	自动（默认开启）	autovacuum 分析

6.3 日志类型

用途	Oracle	SQL Server	MySQL	PostgreSQL
Redo（重做）	Redo Log	Transaction Log	Redo Log（ib_logfile）	WAL
Undo（回滚）	Undo 表空间	Transaction Log（同一份）	Undo Log（undo tablespace）	Old tuple in heap
归档	Archive Log	——（备份 log backup）	Binlog	WAL archive
主从复制	Redo + Archive	Transaction Log	Binlog	WAL stream

关键观察：
  - Oracle / PG 把 Redo 和 Undo 完全分离
  - SQL Server 在同一个 Transaction Log 里同时承担 Redo/Undo
  - MySQL InnoDB 同时有 Redo Log 和 Undo Log，再加上 Binlog
  - 复制日志：MySQL 用 Binlog，其他三家直接用 Redo/WAL/Transaction Log

6.4 索引术语

概念	Oracle	SQL Server	MySQL (InnoDB)	PostgreSQL
主键索引	IOT / 普通索引	Clustered Index	Clustered Index（=数据）	普通索引（堆表）
二级索引	Normal Index	Nonclustered Index	Secondary Index	Index
唯一索引	Unique Index	Unique Index	Unique Index	Unique Index
联合索引	Composite	Composite	Composite	Composite
函数索引	Function-based	Computed Column	Functional（5.7+）	Expression Index
位图索引	Bitmap	——（仅 DW 用）	——	——
倒排索引	——	——	——	GIN
部分索引	——	Filtered	——	Partial Index

后续第 3 篇会展开。

七、选型哲学

讲完架构，最后聊点选型。每家数据库都有它最舒服的场景，没有"银弹"。

Oracle 适合：
  - 核心金融、ERP，对一致性要求极高
  - 预算充足、需要商业支持
  - 需要 RAC 共享存储集群（单库扩展到多节点）

SQL Server 适合：
  - 已是 Windows + .NET 生态
  - 需要 BI 全家桶（SSIS/SSAS/SSRS）
  - 内部团队熟悉 T-SQL
  - 也适合 Linux 部署（2017+）

MySQL 适合：
  - 互联网高并发 OLTP
  - 数据规模可控（单库 TB 级以内）
  - 团队熟悉 LAMP/LEMP 栈
  - 需要多种存储引擎灵活搭配

PostgreSQL 适合：
  - 复杂查询、分析型负载
  - 需要 JSON / JSONB / GIS（PostGIS）
  - 希望使用 BSD-like 许可证
  - 想用 Oracle 但预算不够（PG 的语法/特性最像 Oracle）

7.1 一些常见的误区

误区 1：MySQL 比 PostgreSQL 慢
真相：纯单条 OLTP 写入，InnoDB 通常更快；复杂分析查询 PG 更快。

误区 2：Oracle 一定比开源好
真相：除非用 RAC / Exadata / 高级安全特性，PG/MySQL 8.x 能覆盖大部分场景。

误区 3：PostgreSQL 不能做高并发
真相：配合 pgbouncer + 多实例，PG 也能撑住极高并发；只是默认配置不如 MySQL。

误区 4：SQL Server 只能跑 Windows
真相：2017+ 官方支持 Linux + Docker，但生态工具仍以 Windows 为主。

误区 5：四大数据库的功能都差不多
真相：底层架构差异巨大——进程模型、日志、MVCC、复制、锁——这些都影响生产实践。

八、小结

本文作为开篇，主要做了三件事：

用一行 UPDATE 串联起本系列要讲的 10 个原理子系统
横向对比了四大数据库的身世、进程模型、整体架构
给出四方言核心术语对照表（内存、后台、日志、索引）

记住三句话：
  1. 四大数据库解决的是同一组问题，但答案不同
  2. 进程/线程模型是其他所有差异的根源
  3. 同一个概念在四家里叫不同名字，建立"翻译字典"是基本功

下一篇将从"数据在磁盘上长什么样"开始，深入存储引擎的世界：页、块、Extent、Segment、堆表 vs 索引组织表，以及为什么 MySQL 的主键就是数据本身。