数据库领域正在经历近十年最猛烈的一次"内核复兴"。这不是夸大其词——当 DuckDB 一个进程内分析型数据库在 GitHub 上累积超过几十万星、被嵌入到无数数据管线里时；当 PostgreSQL 凭借 vector search、异步 I/O 和 serverless 变体（如 Neon）持续蚕食专有数据库市场时；当 CMU 的数据库内核课程成为全网工程师"补课"的标配时，我们显然站在一个新周期的起点。
本期 programming（编程与开发） 分类聚焦"数据库引擎内核"，精选 7 个 2025–2026 年最具工程价值的 YouTube 视频/频道。它们的共同点是：不浮于"如何写 SQL"，而是讲清楚引擎内部究竟发生了什么——存储页与元组如何组织、B+ 树与 LSM 树如何取舍、MVCC 如何让读不阻塞写、向量化执行如何把列式存储的性能榨干。
读懂这些内容，你的收获不是"会用某个数据库"，而是具备判断任何数据库优劣的底层坐标系。
| # | 视频/频道 | 核心主题 | 工程深度 | 适合人群 |
|---|---|---|---|---|
| 1 | What is DuckDB? | 进程内列式 OLAP + 向量化执行 | ★★★★ | 数据工程师、全栈 |
| 2 | SQLite vs DuckDB (2026) | 嵌入式 OLTP vs OLAP 选型 | ★★★ | 架构师、独立开发者 |
| 3 | Database Indexing Explained (Hussein Nasser) | 索引原理与代价 | ★★★★ | 后端、DBA |
| 4 | PostgreSQL Internal Architecture | 进程模型/WAL/MVCC | ★★★★★ | 后端、SRE |
| 5 | PostgreSQL 18 Deep Dive | 新版特性（async I/O 等） | ★★★★ | 升级评估者 |
| 6 | CMU 15-445/645 (Andy Pavlo) | 数据库内核系统级课程 | ★★★★★ | 想造 DB 的人 |
| 7 | Scaling Databases in the AI Era | AI 时代数据库演进 | ★★★★ | 技术决策者 |
频道/链接：YouTube · 数据工程方向
这条视频把 DuckDB 的定位讲得极其清晰：它是 OLAP（分析型）世界的 SQLite。就像 SQLite 是一个可以塞进任何进程、零配置、单文件的 OLTP（事务型）数据库一样，DuckDB 是一个可以塞进任何进程、零配置、5 秒安装、能直接嚼碎 CSV/Parquet 的 OLAP 数据库。
最关键的工程洞察是向量化执行（vectorized execution）。传统数据库逐行解释执行查询，每行都要经过函数调用、类型检查的开销；DuckDB 借鉴 MonetDB 的思想，一次处理一批（通常 1024 或 2048 个值）数据，把解释开销摊薄到整批上，同时让 CPU 能利用 SIMD 指令、保持缓存友好。叠加列式存储（只读取查询真正需要的列）和 morsel-driven parallelism（把查询切分成小块分发到所有核心），DuckDB 在单机分析上常常能跑赢需要拉起集群的 Spark。
如果你正在用 Pandas 处理超出内存的数据、或者为了跑一个临时聚合查询就启动一个 Spark 集群，这条视频会改变你的工作流。DuckDB 让"本地 SQL 分析"变得几乎免费——进程内运行、无服务端、直接 SELECT * FROM 'data.parquet'。
适合人群：数据工程师、数据分析师、做本地数据处理的独立开发者、需要给应用加嵌入式分析能力的全栈工程师。
频道/链接：YouTube
2026 年这条"嵌入式数据库选型"视频之所以反复被推荐，是因为它精准戳中了一个普遍误区：很多人以为 DuckDB 是要取代 SQLite 的，其实两者根本不在一个赛道。
视频从架构层做了清晰切分：
INSERT/UPDATE/DELETE 一行行来，延迟低、持久性强。一个反直觉的洞察：选型本质上取决于"你的查询是点查还是扫描"。点查（按主键取一行）选 SQLite；扫描（对几百万行求 SUM/GROUP BY）选 DuckDB。强行用错，性能差几个数量级。
给应用选本地存储时，先问自己：是"存用户状态、频繁增删改"（→SQLite），还是"存日志/事件、批量分析"（→DuckDB）。很多现代应用其实两个都要——用 SQLite 管事务，用 DuckDB 跑分析报表，各司其职。
适合人群：架构师、独立开发者、需要做技术选型的技术负责人。
flowchart TD
A[嵌入式数据库选型] --> B{主要查询模式?}
B -->|点查/事务 增删改| C[SQLite]
B -->|扫描/聚合 分析| D[DuckDB]
C --> C1[行存 + ACID + 单文件]
D --> D1[列存 + 向量化 + 外部文件直读]
C1 --> C2[移动端/嵌入式/本地配置]
D1 --> D2[本地分析/报表/数据科学]
频道/链接：Hussein Nasser · 37.9万次观看
Hussein Nasser 是后端工程领域最被低估的"硬核 YouTuber"之一，这条索引讲解是他播放量最高的视频之一。他没有停留在"索引让查询变快"这种废话，而是讲透了索引的代价。
核心洞察一：索引是空间换时间，更是"写"换"读"。每多一个索引，每一次 INSERT/UPDATE/DELETE 都要同步维护这棵索引树，写放大（write amplification）随之上升。所以"给所有列建索引"是新手最经典的反模式。
核心洞察二：PostgreSQL 支持多种索引类型，选对类型比建索引本身更重要——B-tree 适合范围和等值查询；Hash 只适合等值；BRIN（块范围索引）适合有序大表，占用极小；GIN 适合全文检索和 JSONB；GiST 适合地理/范围数据。
核心洞察三：复合索引的最左前缀原则和部分索引（partial index）、覆盖索引（covering index，PG 用 INCLUDE 实现）的实战用法——这是把慢查询从秒级压到毫秒级的关键。
掌握这套方法后，配合 EXPLAIN (ANALYZE, BUFFERS)，你能独立诊断 90% 的"数据库变慢"问题：看是走了 Seq Scan（全表扫描）还是 Index Scan，估算了多少行，命中了多少缓冲。
适合人群：所有写后端的工程师、DBA、面试中会被问索引原理的求职者。这是"一次学习、终身复利"的知识。
频道/链接：YouTube
如果说上一条讲的是"索引"这一个点，这条讲的是 PostgreSQL 整个引擎的骨架，是理解所有 PG 行为的根基。
进程模型：与 MySQL/Oracle 的多线程不同，PostgreSQL 采用多进程架构（每个连接 fork 一个 backend 进程）。这带来了极佳的稳定性（一个连接崩溃不会拖垮整个数据库），但也意味着连接数不能无限涨——每个进程都占内存，所以 PG 生态演化出了 PgBouncer 这类连接池。理解这一点，才能理解为什么"连接风暴"会把 PG 打挂。
WAL（Write-Ahead Log，预写日志）：所有修改先写日志再改数据页。这是持久性与复制的基石——崩溃恢复靠回放 WAL，主从复制靠传输 WAL。它也解释了为什么 PG 的 synchronous_commit 设置能权衡延迟与安全。
MVCC（多版本并发控制）：这是 PG 最优雅的设计。每次 UPDATE 不就地改，而是写一个新版本（新元组），旧版本标记为死元组。好处是读不阻塞写、写不阻塞读；代价是会产生"膨胀"（bloat），需要 autovacuum 定期回收死元组。不懂 MVCC，就不懂为什么 PG 表会越用越慢、为什么需要 VACUUM。
诊断"表膨胀""连接耗尽""复制延迟""长事务锁等待"这些生产顽疾，底层都靠这套架构知识。它是 SRE 和资深后端的必修内功。
适合人群：PostgreSQL 重度使用者、SRE、想从"会用 PG"升级到"懂 PG"的工程师。
flowchart LR
Client -->|连接| Postmaster
Postmaster --> Backend1[Backend 进程 1]
Postmaster --> Backend2[Backend 进程 2]
Backend1 --> SB[Shared Buffers 共享内存]
Backend2 --> SB
SB -->|刷盘| DF[数据文件 8KB 页]
Backend1 -.先写.-> WAL[WAL 预写日志]
WAL -.崩溃恢复/复制.-> DF
SB -->|MVCC 多版本| T1[新元组]
T1 -.旧版本.-> DT[死元组]
DT -->|autovacuum 回收| Free[可复用空间]
频道/链接：YouTube
每个大版本发布时，"新特性深度解读"类视频都会刷一波流量。PG 18 这条值得看，是因为它讲的不是 changelog 罗列，而是特性背后的工程动机。
最重磅的是异步 I/O（async I/O）。PG 花了很多年才真正落地这件事——视频会解释为什么：PG 的多进程架构、缓冲管理、错误处理都建立在"同步 read() 返回数据"的假设上，要改成异步意味着重写整个 I/O 栈。一旦完成，对于能跑在 io_uring 上的现代系统，大表扫描、备份、复制的吞吐会有可观提升。
此外通常涵盖：改进的 EXPLAIN（更易读的执行计划）、虚拟生成列（virtual generated columns）、增强的索引能力、更智能的增量排序和并行查询。这些不是炫技，而是把"过去需要手动调优才能拿到"的性能变成"开箱即用"。
直接服务于一个决策：你的系统要不要升级到 PG 18？ 这条视频给你评估依据——哪些新特性恰好解决你的痛点（比如异步 I/O 对 I/O 密集型负载、生成列对派生数据）。
适合人群：负责数据库升级规划的技术负责人、追求性能极限的 DBA、对引擎演进感兴趣的工程师。配套可看 Hussein Nasser 的"Why It took Postgres years to do async"，专门拆解异步 I/O 的历史包袱。
频道/链接：CMU Database Group · 25 集完整课程 · 频道主页
这是全球数据库内核教育的"金标准"，主讲 Andy Pavlo 是数据库系统领域最活跃的研究者之一。课程完全开源（CC 协议），免费、系统、硬核，堪称"想造数据库的人的圣经"。
它真正值得精读的几集：
课程最大的价值是用统一框架拆解所有数据库——学完之后，你再看 MySQL、PG、ClickHouse、DuckDB、Spanner，不再是孤立的知识点，而是同一个设计空间里的不同取舍。
适合想要"知其所以然"的资深工程师，尤其是构建中间件、数据基础设施、自研存储引擎的人。配套的 BusTub（CMU 的教学型数据库）代码作业更是把理论变成手感的最佳路径。
适合人群：数据库内核爱好者、基础架构工程师、准备数据库相关面试/读研的人、想从应用层下沉到底层系统的工程师。
flowchart TD
DB[数据库内核设计空间] --> ST[存储层]
DB --> QP[查询处理层]
ST --> ST1{页内组织}
ST1 --> Row[行存 OLTP]
ST1 --> Col[列存 OLAP]
ST --> ST2{索引结构}
ST2 --> BT[B+ 树 读友好]
ST2 --> LSM[LSM 树 写友好]
QP --> QP1[解析/绑定]
QP --> QP2[优化 规则+成本]
QP --> QP3[执行 向量化/编译]
QP3 --> EX1[DuckDB 向量化]
QP3 --> EX2[Hyper/PG JIT 编译]
频道/链接：YouTube
这是一场访谈形式的视频，Pavlo 教授跳出课堂、谈他对AI 时代数据库往哪走的判断，含金量很高。
洞察一：vector search 正在成为关系型数据库的"标配能力"。pgvector 让 PostgreSQL 直接支持向量相似度检索，意味着做 RAG（检索增强生成）、语义搜索不必再单独引入一个向量数据库。Pavlo 的观点是：大多数应用的向量规模，PG 加上合适的索引（HNSW、IVFFlat）完全扛得住，"专用向量库"的护城河正在被侵蚀。
洞察二：HTAP（混合事务分析）与存算分离。云原生时代，存储和计算解耦（如 Neon、Aurora）让数据库能弹性伸缩、按需付费。PG 生态凭借这一点，正在挑战那些专有的云数据库。
洞察三：异步 I/O 与现代硬件的适配（呼应前文 PG 18）。数据库内核长期滞后于硬件演进，现在正在补课。
这条视频是"技术选型战略级输入"。如果你要为一个 AI 应用设计数据层，它会帮你判断：到底要不要上专用向量库？要不要选 serverless PG？如何避免过早优化和过度架构。
适合人群：技术决策者、AI 应用架构师、关注数据库趋势的资深工程师。
flowchart TD
ROOT[数据库引擎内核] --> DIV1[按负载类型]
ROOT --> DIV2[按核心子系统]
ROOT --> DIV3[按时代趋势]
DIV1 --> OLTP[OLTP 事务型]
DIV1 --> OLAP[OLAP 分析型]
OLTP --> SQLite[SQLite 嵌入式]
OLTP --> PG1[PostgreSQL 行存]
OLAP --> DuckDB[DuckDB 嵌入式列式]
OLAP --> CH[ClickHouse]
DIV2 --> STORE[存储: 页/元组]
DIV2 --> IDX[索引]
DIV2 --> CC[并发控制]
DIV2 --> QOPT[查询优化]
STORE --> LSM[LSM 树]
STORE --> BPT[B+ 树]
STORE --> ROWCOL[行存 vs 列存]
IDX --> IDX1[B-tree/Hash/BRIN/GIN]
CC --> MVCC[MVCC 多版本]
CC --> WAL[WAL 预写日志]
QOPT --> VEC[向量化执行]
QOPT --> JIT[JIT 编译]
DIV3 --> VEC2[进程内分析 DuckDB 崛起]
DIV3 --> AI[向量检索 pgvector]
DIV3 --> SERVERLESS[存算分离 serverless]
SQLite -.对比.-> DuckDB
PG1 -.演进.-> PG18[PG18 async I/O]
VEC -.被讲解.-> CMU[CMU 15-445 课程]
把本期 7 个内容连起来看，你会发现一条清晰的进阶路径：先用 SQLite vs DuckDB 建立选型直觉（第二篇）→ 用 Hussein Nasser 的索引视频掌握最常用的高频知识（第三篇）→ 用 PG 架构视频理解生产级引擎的全貌（第四篇）→ 跟着 CMU 课程下沉到内核设计空间（第六篇）→ 最后用 Pavlo 的访谈看清 AI 时代的演进方向（第七篇）。DuckDB 和 PG 18 则是贯穿其中的"当下热点"（第一、五篇）。
数据库是软件系统中最难、也最复利的知识领域之一。一台引擎的设计权衡（读优化还是写优化？强一致还是高可用？通用还是专用？）几乎是所有系统设计的缩影。把这几条视频真正消化掉，你获得的不仅是几个工具的用法，而是一套可以迁移到缓存、消息队列、文件系统乃至分布式协调的底层思维框架。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。