1. 测试环境与数据集准备在开始性能对比之前我们需要先搭建一个公平的测试环境。本次测试使用的是一台配置为24核CPU和64GB内存的工作站操作系统为Windows 11专业版。这样的配置足以处理我们即将测试的超大数据集。测试使用的数据库版本分别为MySQL 8.0.12社区版DuckDB 1.5.1数据集方面我们选择了股票市场数据作为测试样本主要包含三个表主表stock_daily股票日线数据数据量14,150,202行CSV文件大小1.15GB表结构包含股票代码、交易日期、开盘价、最高价、最低价、收盘价等关键金融指标维度表1stock_base股票基本信息数据量5,362行包含股票代码、名称、所属行业、市场类型等基本信息维度表2stock_company上市公司信息数据量5,146行包含公司法人代表、注册资本、注册日期、所在城市等详细信息提示在实际测试中我们同时准备了CSV和Parquet两种格式的文件因为DuckDB可以直接查询这些文件而无需预先加载到数据库中。2. 基础查询性能对比2.1 简单聚合查询我们首先测试最基本的COUNT(*)操作-- MySQL查询 SELECT COUNT(*) FROM stock_daily; -- 耗时8.038秒 -- DuckDB查询CSV文件 SELECT COUNT(*) FROM stock_daily.csv; -- 耗时0.452秒这个简单的测试已经显示出惊人的差异DuckDB比MySQL快了近18倍。这是因为DuckDB是面向分析型查询优化的它可以直接扫描CSV文件而不需要像MySQL那样通过存储引擎层。2.2 分组聚合查询接下来我们测试分组统计操作-- MySQL统计每只股票的交易天数 SELECT ts_code, COUNT(*) FROM stock_daily GROUP BY ts_code; -- 耗时2.627秒 -- DuckDB同样查询 SELECT ts_code, COUNT(*) FROM stock_daily.csv GROUP BY ts_code; -- 耗时0.478秒在这个测试中DuckDB仍然保持了约5.5倍的速度优势。值得注意的是MySQL在这个查询中能够利用到ts_code上的主键索引而DuckDB则是在无索引的情况下完成的。2.3 排序操作我们进一步增加排序操作-- MySQL按交易天数排序 SELECT ts_code, COUNT(*) AS days FROM stock_daily GROUP BY ts_code ORDER BY days; -- 耗时13.16秒 -- DuckDB同样查询 SELECT ts_code, COUNT(*) AS days FROM stock_daily.csv GROUP BY ts_code ORDER BY days; -- 耗时0.495秒这个测试结果更加惊人DuckDB比MySQL快了26倍以上。排序操作是DuckDB的强项因为它采用了更现代的查询执行引擎能够更好地利用现代CPU的并行计算能力。3. 复杂查询场景对比3.1 条件过滤与日期查询我们测试一个典型的业务场景查询特定日期的上涨股票数量。-- MySQL查询 SELECT COUNT(*) AS up FROM stock_daily WHERE trade_date2020-05-07 00:00:00 AND close open; -- 耗时4.194秒 -- DuckDB查询 SELECT COUNT(*) AS up FROM read_csv(stock_daily.csv, auto_detecttrue) WHERE trade_date DATE 2020-05-07 AND close open; -- 耗时0.511秒在这个测试中DuckDB保持了约8倍的速度优势。虽然MySQL在trade_date字段上有索引但对于这种需要扫描大量数据的查询索引的优势并不明显。3.2 多表关联查询真正的性能差异出现在多表关联查询中。我们测试一个需要关联两个表的查询-- MySQL按行业分组统计上涨股票 SELECT b.industry, COUNT(*) AS up FROM stock_daily a LEFT JOIN stock_base b ON a.ts_code b.ts_code WHERE a.trade_date2020-05-07 00:00:00 AND a.close a.open GROUP BY b.industry ORDER BY up DESC; -- 耗时4.705秒 -- DuckDB同样查询 SELECT b.industry, COUNT(*) AS up FROM read_csv(stock_daily.csv) a LEFT JOIN read_csv(stock_base.csv) b ON a.ts_code b.ts_code WHERE a.trade_date DATE 2020-05-07 AND a.close a.open GROUP BY b.industry ORDER BY up DESC; -- 耗时0.596秒DuckDB在这个复杂查询中仍然保持了近8倍的速度优势。值得注意的是DuckDB是直接从CSV文件执行这个关联查询的而MySQL需要先将数据加载到数据库中。3.3 三表关联查询我们进一步增加复杂度测试一个需要关联三个表的查询-- MySQL查询 SELECT c.exchange, b.industry, COUNT(*) AS up FROM stock_daily a LEFT JOIN stock_base b ON a.ts_code b.ts_code LEFT JOIN stock_company c ON a.ts_code c.ts_code WHERE a.trade_date2020-05-07 00:00:00 AND a.close a.open GROUP BY c.exchange, b.industry ORDER BY up DESC; -- 耗时4.705秒 -- DuckDB查询 SELECT c.exchange, b.industry, COUNT(*) AS up FROM read_csv(stock_daily.csv) a LEFT JOIN read_csv(stock_base.csv) b ON a.ts_code b.ts_code LEFT JOIN read_csv(stock_company.csv) c ON a.ts_code c.ts_code WHERE a.trade_date DATE 2020-05-07 AND a.close a.open GROUP BY c.exchange, b.industry ORDER BY up DESC; -- 耗时0.883秒即使在这个更复杂的查询中DuckDB仍然比MySQL快了5倍以上。这展示了DuckDB在处理复杂分析查询时的强大能力。4. 性能差异的深层次原因4.1 架构设计差异MySQL是一个传统的OLTP在线事务处理数据库其设计重点是保证ACID特性和高并发的事务处理能力。而DuckDB是一个OLAP在线分析处理数据库专门为分析型查询优化。关键区别包括存储格式MySQL使用行存储适合点查询DuckDB默认使用列存储适合分析查询执行引擎MySQL使用传统的火山模型DuckDB使用向量化执行引擎并行处理DuckDB能更好地利用多核CPU并行执行查询4.2 数据加载方式在我们的测试中DuckDB是直接从CSV文件查询的而MySQL需要先将数据加载到数据库中。这实际上给了MySQL一个不公平的优势因为预加载数据通常应该比直接查询文件更快。但测试结果显示即使如此DuckDB仍然大幅领先。4.3 索引的影响MySQL在trade_date字段上建立了索引理论上应该加速日期过滤查询。但在我们的测试中这个优势并不明显因为即使使用索引MySQL仍然需要访问大量数据页DuckDB的列存储格式可以跳过不相关的数据块DuckDB的向量化处理可以更高效地处理批量数据5. 实际应用建议5.1 何时选择DuckDB基于测试结果DuckDB在以下场景中表现优异需要快速分析大量数据特别是临时性分析数据以文件形式存在不想经历繁琐的数据库导入过程查询涉及复杂的聚合、排序和多表关联需要在资源有限的机器上运行分析查询5.2 何时坚持使用MySQLMySQL仍然是以下场景的更好选择需要高并发的OLTP操作如电商交易系统需要严格的ACID保证系统已经基于MySQL构建迁移成本高需要成熟的用户权限管理和企业级功能5.3 性能优化技巧对于DuckDB将频繁查询的数据转换为Parquet格式可以获得更好的性能对经常查询的列使用适当的压缩编码考虑为常用查询创建物化视图对于MySQL确保为分析查询创建适当的复合索引考虑使用MySQL的分析引擎如HeatWave对大表进行分区可以提高查询性能6. 测试的局限性虽然我们的测试展示了DuckDB在分析查询上的显著优势但需要注意以下几点测试场景有限我们只测试了特定类型的分析查询没有测试事务处理能力硬件影响在SSD上两者的性能差距可能会缩小数据规模对于更大的数据集TB级别结果可能会有所不同MySQL优化专业的DBA可能能够通过优化配置获得更好的MySQL性能在实际项目中选择数据库应该基于全面的需求分析而不仅仅是原始查询速度。系统架构、团队技能、运维成本等因素都应该纳入考虑。
