RDS MySQL分析查询慢？用DuckDB列式存储提速百倍实操指南

去年帮一位做跨境电商的朋友排查报表卡顿他开了一个月的订单明细有 1800 万行一条“按品类汇总上个月销售额”的 SQL 在 RDS MySQL 上跑了整整 44 秒。加了索引、调了参数还是解决不了。最后改用 RDS DuckDB 的组合同一个查询降到了不到 400 毫秒一百多倍的速度提升。这不是玄学也不是换了个更贵的数据库而是把“行存”和“列存”做了正确的分工。RDS如 MySQL天生是行存储为 OLTP 高频增删改设计而分析查询恰恰需要扫描大量数据做聚合行存储在这个场景里是硬伤。DuckDB 则是专门为分析场景设计的嵌入式 OLAP 引擎直接把分析查询从 RDS 上卸下来用列式存储 向量化执行跑速度自然快得多。这篇东西面向零基础、又没打算迁移数仓的朋友核心解决三件事一是 RDS 跑分析到底慢在哪二是 DuckDB 为什么能把查询提速百倍三是最关键的——怎么一步一步把 RDS 数据搬到 DuckDB 并加速真实查询。1. RDS 上跑分析为什么这么慢先搞清楚“慢”到底慢在哪很多人的第一反应是“服务器不行”于是升级 CPU、换 SSD、改参数折腾一圈收效甚微。问题不在硬件也不在网络而在存储引擎的工作方式上。1.1 行存的代价一个全表扫描的真实账RDS 上最常见的是 MySQL InnoDB它是典型的行式存储。每一行数据在磁盘上物理连续存放中间靠 BTree 索引组织。好处是插入、更新单条记录极快因为一次 IO 就能把整行读出来坏处是做分析查询时非常吃亏。分析查询往往是这样的SELECT category, COUNT(*), SUM(amount) FROM orders WHERE created_at 2025-01-01 AND created_at 2025-02-01 GROUP BY category;这种查询需要扫描大量行的特定几列。行式存储必须把一整行数据包括你根本用不上的 20 个字段全读出来哪怕你只要其中 3 列磁盘读取量也不会减少。1800 万行、平均每行 600 字节全表扫描一次就要读 10 GB 以上的数据。按普通云盘 200 MB/s 的吞吐算光读数据就要几十秒。更糟的是没有合适索引时MySQL 只能走全表扫描这是行存的天花板。1.2 在线业务与分析查询的“抢资源”矛盾RDS 不只是跑报表线上订单还在实时写入。分析查询耗 CPU、拖慢响应、拉满 IO很容易把线上接口拖垮。很多团队为了避免影响线上只能把报表放到后半夜跑或者加只读从库。但只读从库用的还是同样的行存引擎慢的问题并没有解决只是换了一台机器慢而已。归根到底RDS 不适合做大数据的聚合分析。它的引擎为 OLTP 优化拿它做 OLAP 是拿货车拉货却偏要装成赛车。真正适合分析的是列式存储只读取需要的列配合更好的压缩比例和向量化计算才能从根上提速。2. DuckDB 的原理它是怎么把“慢查询”变成“快查询”的DuckDB 本质是一个嵌入式 OLAP 数据库类似 SQLite 在 OLTP 中的地位但方向完全不同。它直接集成进你自己的进程不需要独立服务器启动快、部署简单却能利用本机所有 CPU 核心和大内存做分析。2.1 列式存储与压缩数据量直接砍半以上列式存储让查询只读需要的列。同样查上述订单场景DuckDB 只需要读取 category、created_at、amount 三个列每组数据在磁盘上连续排列还允许对每列做独立压缩。例如金额字段很多值重复度高DuckDB 会自动套用字典压缩、位压缩、常量压缩等算法。实际经验里一份原始 CSV 是 6.8 GB导入 DuckDB 后往往只剩 1.5 GB 到 2 GB 大小读取量大幅下降查询自然快。2.2 向量化执行引擎从“一件一件扫”到“一车一车拉”MySQL 执行查询通常是逐行迭代火山模型每读一行都要做一次函数调用、类型判断CPU 利用率很低。DuckDB 采用的是向量化执行每批次同时处理 2048 行数据一个 vector整个管道按批次流动。这种模型对 CPU 缓存更友好能最大化利用现代处理器的 SIMD 指令。也就是说DuckDB 并不只是“存储方式不同”而是连计算引擎的执行方式都是为大吞吐量设计的。这是你说“为什么能快百倍”时的核心答案。2.3 元数据与过滤MinMax 索引让“全表扫描”变“全表跳过”DuckDB 在读取数据时会自动维护每个数据块的 min/max 元数据。查询带上了过滤条件它会先看元数据如果整个 block 的最大值都小于过滤条件的下界直接跳过这个 block读都不用读。这意味着数据按时间顺序排列时按时间去 filter 的查询经常只需要读少数几个 block扫描量比“全表扫描”少一两个数量级。关于性能对比一张 1800 万行订单表在 RDS MySQL 和 DuckDB 上的典型表现如下查询场景RDS MySQL 耗时DuckDB 耗时按时间范围聚合金额30-50 秒0.3-0.6 秒跨月 group by 多个维度60-90 秒1-2 秒明细带过滤分页3-8 秒0.1-0.4 秒多表 join 后聚合超过 2 分钟2-5 秒注意 DuckDB 耗时已经包含了大部分冷启动时间如果是连续查询同一份数据第二轮还能更快。3. 零基础实操把 RDS 数据搬到 DuckDB 的三条路原理说得再漂亮还是要落地。这里我按从易到难的顺序给出三种把 RDS 数据导入 DuckDB 的方式并附上可复制的命令和脚本供不同场景参考。3.1 环境准备DuckDB 的几种装法DuckDB 安装非常简单无需配置服务端几个常见方式如下命令行 CLI下载 DuckDB CLI 的二进制文件即可解压后直接运行。Python执行pip install duckdb然后引入包就能用。JDBC / ODBC适合 Java、PowerBI 等生态下载对应的驱动。作为库嵌入应用比如 Go、Rust、Node.js 都有官方绑定。最省事的入门方式是把 DuckDB CLI 下载下来放进/usr/local/bin/duckdb或当前用户目录然后运行duckdb mydb.duckdb如果还没下载可以先前往 DuckDB 官网的 download 页面选择对应操作系统的 CLI 包。没有多余配置启动即用这在后面调试数据链路时特别顺手。3.2 方式一CSV 落地最通用、最容易踩坑但最稳这种方式最适合第一次上手逻辑简洁从 RDS 导出 CSV再由 DuckDB 读入。先在 RDSMySQL侧导出数据注意用SELECT ... INTO OUTFILE方式导出避免把标题行也带进数据文件里。-- 在 MySQL 客户端执行 SELECT order_id, category, amount, created_at FROM orders INTO OUTFILE /tmp/orders.csv FIELDS TERMINATED BY , ENCLOSED BY LINES TERMINATED BY \n;如果你的 RDS 不具备直接写本地文件的权限也可以分页查询比如用 Python 的pymysql分批把数据拉下来写到本地文件。推荐这种更通用import pymysql import csv conn pymysql.connect(hostrds-host, user..., password..., database...) cursor conn.cursor() cursor.execute(SELECT order_id, category, amount, created_at FROM orders) with open(orders.csv, w, newline) as f: writer csv.writer(f, delimiter,) for row in cursor: writer.writerow(row) cursor.close() conn.close()然后启动 DuckDB创建一个新数据库直接建表导入CREATE TABLE orders AS SELECT * FROM read_csv_auto(/tmp/orders.csv);read_csv_auto会自动推断字段类型省去写 DDL 的繁琐。导入后再建立一个适合查询的宽表也没问题DuckDB 原生就支持。3.3 方式二JDBC 直连导出省去中间文件如果不想落本地 CSV 文件而是想直接从 RDS 拉数据可以使用 DuckDB 的 MySQL 扩展INSTALL mysql; LOAD mysql; ATTACH hostrds-host user... password... port3306 databaseorders_db AS rds (TYPE mysql); CREATE TABLE orders AS SELECT * FROM rds.orders;这种方案适合一次性的初始全量导入数据直接跨库拷贝不需要中间落地文件。十几万行毫无压力几百万行也可以接受但拉到几千万行时耗时就会比 CSV 更久因为它仍然经过行式读取与网络传输。3.4 方式三增量同步脚本日常更新的正确姿势全量导入只有第一次有意义。日常更新需要一个增量同步脚本我用 Python 举例流程是记录上次同步的游标一般用主键或更新时间拉取增量数据再通过 DuckDB 的 Python API 去更新import duckdb import pymysql # 读取上次同步位置 with open(last_cursor.txt) as f: last_cursor f.read().strip() src pymysql.connect(hostrds-host, ...) cursor src.cursor() cursor.execute( SELECT order_id, category, amount, created_at FROM orders WHERE order_id %s ORDER BY order_id LIMIT 10000, (last_cursor,) ) rows cursor.fetchall() con duckdb.connect(mydb.duckdb) con.execute(DELETE FROM orders WHERE order_id ?, (last_cursor,)) con.executemany( INSERT INTO orders (order_id, category, amount, created_at) VALUES (?, ?, ?, ?), rows ) con.close() with open(last_cursor.txt, w) as f: f.write(str(rows[-1][0])) cursor.close() src.close()删除再插入是为了保证幂等避免重复导入造成数据翻倍。游标选择主键或更新时间均可若频繁更新已有行以updated_at为游标更稳妥。4. 不要以为导入就完事让查询再快一步的调优三板斧很多人第一次导入后发现查询已经很快但还想要更快。这里分享三个我实测很有效的调优手段。4.1 先排序后建表让压缩率额外提升 30% 以上数据按时间排序时相同品类、相似金额的量会聚在一起压缩率会明显变好MinMax 索引的跳过效果也更出色。用 DuckDB 建表时可以按某个字段预排序CREATE TABLE orders_sorted AS SELECT * FROM orders ORDER BY created_at;如果表已经建好也可以直接建一个排序后的副本覆盖原表CREATE OR REPLACE TABLE orders AS SELECT * FROM orders ORDER BY created_at;注意排序本身会花一点时间但这个时间在后续每次范围查询里都能赚回来。实测中按时间列排序后即使同为全量扫描压缩后读盘量也能再省一截。4.2 做好冷热分区用文件目录代替单表大文件DuckDB 支持直接把多个 parquet 文件作为一个外部表查询天然按文件跳过例如SELECT * FROM read_parquet(/data/orders/month01/*.parquet);你可以将 RDS 数据按月份导出为多个 parquet 文件放置到不同子目录比如month2025-01、month2025-02DuckDB 在有过滤条件时会借助 Hive 风格分区自动跳过无关目录。这种模式下查询一个月的明细就只读那个月的文件几十倍性能提升非常常见。导出 parquet 的方法可以在 DuckDB 里直接执行COPY (SELECT * FROM orders WHERE created_at 2025-01-01 AND created_at 2025-02-01) TO /data/orders/month2025-01/orders.parquet (FORMAT PARQUET);这也符合“列存 文件 分析数据库”的核心思路。即使本地同时有好几年数据也无须每次都全量扫描。4.3 定时刷新物化视图把预计算做在前端有些查询是每天都跑的固定报表比如按小时统计订单、按渠道统计转化率。既然每次都要重新聚合不如定时把这些聚合结果算好存成小表上层报表只查询几百行结果而不是原始千万行。在 DuckDB 里可以做物化表语法类似CREATE TABLE daily_sales_agg AS SELECT date_trunc(day, created_at) AS day, category, SUM(amount) AS total, COUNT(*) AS cnt FROM orders GROUP BY 1, 2;之后用一个 cron 或调度平台定时刷新# 每天凌晨 2 点跑一次 0 2 * * * duckdb mydb.duckdb -c DELETE FROM daily_sales_agg; INSERT INTO daily_sales_agg SELECT ...前端报表直接查这张表延迟以毫秒计。分析场景里预聚合的价值往往被低估——计算量是固定的但数据规模会增长而预聚合能锁定底层扫描成本。5. 用之前必须想清楚的几个问题DuckDB 不是万能加速器DuckDB 确实好用但“百倍加速”有条件。它解决的是分析师和开发者的单机分析场景不是所有问题的银弹。这里把最常被忽略的几个边界问题讲透。5.1 数据新鲜度加速与分析的一致性怎么取舍DuckDB 里的数据是 RDS 的一个副本。同步有延迟就不可能和线上实时一模一样。对决策报表来说T1 或 5 分钟延迟通常可接受但如果你需要实时查看刚下单的一笔订单那 DuckDB 就不适合直接做唯一数据源。比较好的做法是分层实时指标仍然走线上库事后分析、报表、财务对账走 DuckDB。对账类任务刚好需要快照一致性这个用副本再合适不过。我在自己团队里就是这么分工的线上库管现状DuckDB 管过去和趋势。5.2 并发与写入冲突两个连接改同一个文件会发生什么DuckDB 支持多版本并发控制MVCC但它的定位是“单进程多线程”不适合多进程高并发写入。如果多个进程同时连接同一个 DuckDB 文件并执行写操作可能出现锁冲突或者需要很强的性能隔离。线上业务的大并发读写还是留在 RDS 里更合适。简单理解DuckDB 像一把锋利的手术刀适合在离线和半离线场景里单机使用RDS 像后台系统适合支撑全公司的实时请求。两者不是竞争关系而是分工关系。5.3 什么时候你其实需要来个更重的分析引擎如果你有几十亿行数据、需要多人同时在同一个语义层上做复杂分析、有高昂的运维预算那么单机 DuckDB 的内存和并发上限迟早会碰到瓶颈。那时更适合使用基于列存的分析型数据仓库服务比如 ClickHouse、StarRocks或云上的数仓产品。一个简单的判断方式数据量在几 GB 到几十 GB单机跑分析想要零运维DuckDB 是首选。数据量在几百 GB 到数 TB需要稳定的增量同步和更复杂权限管控考虑独立数仓引擎。数据量在几十 TB 以上有多团队协作需求尽快规划真正的数仓平台。DuckDB 更适合作为“本地分析层”存在它能让一个没有专职数仓工程师的团队也能用上真正高效的列存分析能力。就我个人的实际感受RDS 负责在线交易DuckDB 负责分析与报表整套组合部署成本几乎为零却把报表查询从“等得着急”变成“秒出”。如果手头正被 RDS 的分析查询性能卡住别急着升级实例规格先花一小时把这个方案跑通大概率会有惊喜。