DuckDB与MySQL大数据性能对比实测

1. 项目概述：当DuckDB遇上MySQL的大数据对决

上周在优化公司一个数据分析项目时，我遇到了一个经典的技术选型问题：面对超过2TB的销售记录数据，是用传统的MySQL还是尝试新锐的DuckDB？这个问题看似简单，但实际测试结果却让我大吃一惊。本文将分享我的完整测试过程和结论，包含从环境搭建到查询优化的全流程实录。

DuckDB作为一个新兴的嵌入式分析型数据库，近年来在OLAP领域崭露头角。而MySQL作为关系型数据库的常青树，在大数据处理场景下是否还能保持优势？我设计了一套包含6种典型查询场景的测试方案，在相同硬件环境下对两个数据库进行了全面对比。测试数据量从100万条到10亿条逐步递增，覆盖了单表查询、多表关联、聚合计算等常见操作。

重要提示：所有测试均在配备32GB内存和NVMe SSD的同一台物理机上进行，排除了硬件差异对结果的影响。测试使用的MySQL版本为8.0.32，DuckDB版本为0.8.1。

2. 测试环境搭建与数据准备

2.1 硬件与基础软件配置

测试机器采用Dell PowerEdge R740服务器，具体配置如下：

• CPU: 2×Intel Xeon Silver 4210 (10核20线程)
• 内存: 32GB DDR4 ECC
• 存储: 2TB Intel P4510 NVMe SSD
• 操作系统: Ubuntu 22.04 LTS

为确保测试公平性，两个数据库均采用默认配置启动，没有进行特定优化。MySQL通过APT源安装，DuckDB则直接下载预编译的Linux二进制包。

2.2 测试数据集生成

使用Python的Faker库生成模拟电商数据，包含以下核心表结构：

python复制# 订单主表结构示例
orders = {
    "order_id": "UUID",
    "user_id": "Integer(1-1000000)",
    "order_date": "DateTime(2020-01-01至2023-12-31)",
    "total_amount": "Decimal(10,2)(50-20000)",
    "payment_method": "Enum(credit_card,paypal,bank_transfer)"
}

# 订单明细表结构示例
order_items = {
    "item_id": "UUID",
    "order_id": "FK→orders",
    "product_id": "Integer(1-50000)",
    "quantity": "Integer(1-10)",
    "unit_price": "Decimal(10,2)(5-2000)"
}

数据规模按以下梯度生成：

• 小数据集：100万订单，500万明细
• 中数据集：1000万订单，5000万明细
• 大数据集：1亿订单，5亿明细
• 超大数据集：10亿订单，50亿明细

3. 核心测试场景设计

3.1 单表全字段扫描性能

sql复制-- 测试SQL示例
SELECT * FROM orders 
WHERE order_date BETWEEN '2022-01-01' AND '2022-12-31';

这个场景测试数据库的原始IO吞吐能力和列存/行存差异。DuckDB采用列式存储，理论上在大数据量下应有优势。

3.2 多表关联查询性能

sql复制-- 三表关联查询
SELECT o.order_id, o.user_id, SUM(oi.quantity * oi.unit_price) as actual_amount
FROM orders o
JOIN order_items oi ON o.order_id = oi.order_id
JOIN products p ON oi.product_id = p.product_id
WHERE o.order_date >= '2023-01-01'
GROUP BY o.order_id, o.user_id
HAVING ABS(actual_amount - o.total_amount) > 100;

此查询涉及三表关联和聚合计算，考验数据库的JOIN算法和并行处理能力。

3.3 复杂聚合分析性能

sql复制-- 多层聚合分析
SELECT 
    DATE_TRUNC('month', order_date) as month,
    payment_method,
    COUNT(DISTINCT user_id) as unique_users,
    SUM(total_amount) as gross_volume,
    AVG(total_amount) as avg_order_value
FROM orders
WHERE order_date BETWEEN '2021-01-01' AND '2023-12-31'
GROUP BY 1, 2
ORDER BY 1, 2;

这类分析查询是OLAP系统的典型负载，测试数据库的向量化执行能力。

4. 实测性能对比与分析

4.1 数据加载速度对比

DuckDB的列式存储格式在数据加载时展现出巨大优势，特别是大数据量下速度差异可达4-5倍。MySQL的ACID保证带来了显著的写入开销。

4.2 查询响应时间对比(单位：秒)

关键发现：当数据量超过1亿条后，MySQL在多数复杂查询上会超时(超过10分钟)，而DuckDB仍能保持响应。在简单查询上，两者差距约2-3倍；复杂分析查询差距可达5-10倍。

4.3 内存使用情况对比

在1亿数据量测试中：

• MySQL峰值内存使用：约18GB
• DuckDB峰值内存使用：约6GB

DuckDB的内存效率明显更高，这得益于其：

1. 列式存储只需加载查询涉及的列
2. 更紧凑的数据编码格式
3. 基于矢量的执行模型减少中间结果

5. 深度技术解析

5.1 DuckDB的性能奥秘

1. 列式存储引擎：按列存储数据，查询时只需读取相关列，大幅减少IO
2. 向量化执行：以批处理方式(通常1024行/批)处理数据，充分利用CPU缓存
3. 零拷贝设计：数据在磁盘和内存中的格式一致，避免反序列化开销
4. 智能并行化：自动利用多核CPU并行执行查询计划

python复制# DuckDB的Python API示例
import duckdb
conn = duckdb.connect(':memory:')
conn.execute("CREATE TABLE orders AS SELECT * FROM 'orders_1b.parquet'")
result = conn.execute("SELECT payment_method, AVG(total_amount) 
                      FROM orders GROUP BY payment_method").fetchall()

5.2 MySQL的瓶颈分析

1. 行式存储：即使只查询少数列，也需要读取整行数据
2. 缓冲池管理：需要维护复杂的缓冲池机制处理磁盘IO
3. 事务开销：MVCC机制带来额外的版本控制负担
4. 执行模型：传统的火山模型逐行处理效率较低

6. 实战建议与避坑指南

6.1 何时选择DuckDB

1. 分析型工作负载：复杂聚合、大规模扫描查询
2. 嵌入式场景：需要轻量级、零管理的分析引擎
3. 数据探索阶段：快速迭代的分析需求
4. 内存受限环境：需要处理比内存大的数据集时

6.2 何时坚持使用MySQL

1. 高并发OLTP：大量短事务、随机点查询
2. 数据一致性要求高：需要完整ACID支持
3. 已有成熟生态：与现有系统深度集成
4. 复杂写操作：频繁的UPDATE/DELETE操作

6.3 性能优化技巧

DuckDB优化：

• 使用PARQUET格式存储数据（比CSV快3-5倍）
• 对常用过滤条件创建合适的索引

sql复制-- 创建索引示例
CREATE INDEX idx_order_date ON orders(order_date);

• 调整内存限制（默认使用80%可用内存）

sql复制SET memory_limit='16GB';

MySQL优化：

• 为分析查询创建专用列索引

sql复制ALTER TABLE orders ADD COLUMN order_date_year YEAR AS (YEAR(order_date)) STORED;
CREATE INDEX idx_order_date_year ON orders(order_date_year);

• 使用查询重写简化复杂分析
• 考虑使用MySQL HeatWave引擎（需企业版）

7. 典型问题排查实录

7.1 DuckDB查询卡住

现象：10亿数据量下某些查询长时间无响应
排查：

1. 检查系统内存是否耗尽（使用htop观察）
2. 查看DuckDB线程状态

bash复制ps -T -p <duckdb_pid>

3. 尝试降低并行度

sql复制SET threads TO 4;

解决：添加更多过滤条件减少数据扫描量，或增加memory_limit

7.2 MySQL查询超时

现象：复杂关联查询返回"Lost connection to MySQL server"
排查：

1. 检查wait_timeout设置（默认8小时）

sql复制SHOW VARIABLES LIKE 'wait_timeout';

2. 增大排序缓冲区

sql复制SET sort_buffer_size = 256*1024*1024;

3. 使用EXPLAIN分析执行计划
   解决：重写查询为多个简单步骤，或考虑使用ETL预处理数据

8. 扩展应用场景

8.1 混合使用模式

在实际项目中，可以采用混合架构：

• MySQL作为主业务数据库处理交易
• 定期将数据同步到DuckDB进行分析
• 使用DuckDB的HTTP扩展构建轻量级分析API

python复制# 数据同步示例（使用Python）
import mysql.connector
import duckdb

# 从MySQL导出
mysql_conn = mysql.connector.connect(host="localhost", user="root", database="sales")
cursor = mysql_conn.cursor(dictionary=True)
cursor.execute("SELECT * FROM orders WHERE order_date >= %s", ('2023-01-01',))

# 导入DuckDB
duckdb_conn = duckdb.connect('sales_analysis.db')
duckdb_conn.execute("CREATE TABLE orders AS SELECT * FROM mysql_orders")

8.2 数据科学集成

DuckDB与Python数据科学生态无缝集成：

python复制# 直接查询转为Pandas DataFrame
df = duckdb.query("""
    SELECT product_id, AVG(unit_price) as avg_price
    FROM order_items 
    GROUP BY product_id
    HAVING COUNT(*) > 100
""").to_df()

# 与PyArrow交互
arrow_table = duckdb.query("FROM orders").arrow()

经过这次全面对比，我的结论是：对于分析型查询，特别是在大数据量场景下，DuckDB确实展现出显著优势。但在需要高并发写入或完整事务支持的场景，MySQL仍是更稳妥的选择。实际项目中，最佳方案往往是两者的有机结合，各取所长。