DeepSeek总结的数据库性能教学文章

原文地址：https://bgithub.xyz/DBatUTuebingen-Teaching/didi-ws2526

数据库查询性能的演进：从脚本到并行优化

作者：Torsten Grust
时间：2025/26年冬季学期
单位：德国图宾根大学

---

引言：性能工程的起点

数据库管理系统（DBMS）通过充分利用现代计算机架构中的CPU多线程、内存层次结构（DRAM、缓存）及SSD等存储设备，实现了高效的数据处理。即便是最微小的性能优化，在面对数百万行数据处理时，也会产生显著的放大效应。

本文以一个简单的查询任务为切入点，逐步展示从脚本语言到手工优化的C代码，再到现代DBMS（DuckDB）在性能上的巨大差异。该任务为：读取TPC-H基准测试中的lineitem表（约720MB），并对第五列quantity字段求和。

---

一、性能极限：理论下限

在开始优化之前，作者首先测定了硬件的理论性能极限：

• DRAM读取带宽：21 GB/s → 理论查询时间：0.03s
• NVMe SSD：5 GB/s → 0.14s
• USB-C SSD：800 MB/s → 0.90s
• 以太网：2.5 GB/s → 0.28s

这些数值是基于I/O带宽的理想情况，忽略了CPU处理开销，作为后续优化的参考上限。

---

二、逐步优化：从awk到多线程C

1. awk脚本（解释型语言）

awk -F '|' '{sum += $5} END {print sum}' lineitem.csv

• 查询时间：1.60s
• 吞吐量：471 MB/s
• 问题：CPU成为瓶颈，即使文件缓存在DRAM中也无济于事。

---

2. Python（字节码解释）

逐行读取、拆分、类型转换。

• 查询时间：2.75s
• 吞吐量：275 MB/s
• 性能更低，适合快速开发但不适合大规模数据处理。

---

3. C语言 + getline()

使用标准C库逐行解析。

• 查询时间：0.50s
• 吞吐量：1.5 GB/s
• 性能大幅提升，但getline()和atoi()占用大量CPU（58% + 14%）。

---

4. C + mmap()

使用mmap()一次性将文件映射到内存，避免逐行系统调用。

• 冷缓存：1.6s（受限于磁盘I/O）
• 热缓存：0.42s（吞吐量1.8 GB/s）
• 问题：逐字节扫描查找换行符\n成为新瓶颈（占53% CPU）。

---

5. C + mmap + 块级换行搜索

使用64位字块并行查找换行符，利用位运算宏HAS_NL()。

• 查询时间：0.27s
• 吞吐量：2.8 GB/s
• 性能与strchr()相当，但代码复杂度显著上升。

---

6. C + mmap + 多线程

将文件按换行符划分为12个分区，每个线程独立求和。

• 查询时间：0.04s
• 吞吐量：18.8 GB/s
• 逼近DRAM带宽上限，展现了多核并行处理的巨大优势。

---

三、SQL引擎的极致：DuckDB

作者使用DuckDB对同一数据执行SQL查询：

SELECT sum(l_quantity) FROM read_csv('lineitem.csv');

• 查询时间：0.448s（首次读取）
• 将数据导入DuckDB存储格式后：

SELECT sum(l_quantity) FROM lineitem;

• 查询时间：0.002s
• CPU总时间：0.007s
• 吞吐量远超所有手工实现

---

性能来源分析：

1. 列式存储 ：只读取l_quantity列，避免扫描整行。
2. 投影下推：查询计划仅访问所需字段。
3. 二进制存储：无需重复解析文本。
4. 并行执行：自动利用多核。
5. 内存驻留：数据完全加载于DRAM。

---

四、总结：性能工程的启示

实现方式	查询时间	吞吐量
awk	1.60s	471 MB/s
Python	2.75s	275 MB/s
C + getline	0.50s	1.5 GB/s
C + mmap	0.27s	2.8 GB/s
C + mmap + 线程	0.04s	18.8 GB/s
DuckDB (SQL)	0.002s	>20 GB/s

50年过去了，关系模型的查询优化依然是活跃的研究领域。

即使是个人笔记本电脑，也能实现每秒数GB的数据处理能力。现代DBMS的性能并非依赖"大铁器"或集群，而是通过对硬件特性的深度理解和精细的性能工程实现的。