Metabase 性能测试实战：10 万到 1000 万行数据，慢在哪、怎么调

Metabase 性能测试实战：10 万到 1000 万行数据，慢在哪、怎么调

【免费下载链接】metabaseThe easy-to-use open source Business Intelligence and Embedded Analytics tool that lets everyone work with data :bar_chart:项目地址: https://gitcode.com/GitHub_Trending/me/metabase

Metabase 性能测试的核心结论：同一套部署，数据从 10 万行涨到 1000 万行，查询响应时间会从 200-500ms 拉长到 5-15 秒，内存占用从 1-2GB 涨到 4-8GB 以上。本文不复述测试报告，而是带你走一遍真实排查流程：先按数据规模对照基准判断"慢是否异常"，再定位瓶颈到底在数据库还是在 Metabase 配置，最后给出缓存、连接池、索引这几件最常用的优化手段和验证方法。

📐 第一步：先建立基准，判断你的慢算不算异常

排查性能问题前，先要知道"正常值"是多少。下面这组基准覆盖了三个常见数据规模，你可以拿自己环境的实测值和它对照。

如果你的实测值明显超出对应区间，再往下排查；如果在区间内，说明系统工作正常，慢的原因是查询本身太重，而不是部署问题。

测试环境的搭建很简单，用 Docker 起一个容器，把 Metabase 的应用数据库指到你的 PostgreSQL 实例：

docker run -d -p 3000:3000 \ -e MB_DB_TYPE=postgres \ -e MB_DB_DBNAME=metabase \ -e MB_DB_HOST=your-postgres-host \ -e MB_DB_USER=username \ -e MB_DB_PASS=password \ --name metabase metabase/metabase:latest

几个环境变量说明：MB_DB_TYPE指定应用数据库类型（这里是 postgres）；MB_DB_HOST填你 PostgreSQL 的主机地址；MB_DB_DBNAME、MB_DB_USER、MB_DB_PASS分别是库名、用户名和密码；-p 3000:3000把容器内的服务端口映射到本机 3000 端口。把示例值换成你自己的连接信息后执行即可。

🔍 第二步：定位瓶颈——是数据库慢，还是 Metabase 慢？

很多"Metabase 很慢"的工单，最后发现锅在数据库。官方排障流程的核心思路是一条对比实验，你可以照着做：

1. 先看负载是否真的涨了。查数据库服务端日志，确认是不是表在变大、用 Metabase 的人变多了、访问频率变高了，或者有别的脚本、应用也在频繁打这个库。这一步能排除大量"错觉型"慢查询。
2. 跑一次对照实验。在 Metabase 里执行一个慢的 Question，然后把它的原生 SQL 拿到数据库里直接执行，对比两边耗时：
   • 两边耗时差不多：瓶颈在数据库侧。数据或用量已经超出了数据库的承载能力，要么给数据库加资源，要么考虑换更强的数仓硬件。
   • Metabase 明显更慢：瓶颈在 Metabase 的部署方式，重点看连接池和排队情况，进入第三步。
3. 检查有没有"查询踩踏"。如果有脚本或某个卡片过多的仪表板一次性放出上百个查询，会瞬间占满 Metabase 到数据库之间的所有连接，后面的查询全部排队。处理办法：先停掉肇事进程，再去数据库服务端终止在途查询，然后按需调大连接池上限，见 环境变量文档 里的MB_JDBC_DATA_WAREHOUSE_MAX_CONNECTION_POOL_SIZE。
4. 顺手做一次连接重置。到 Admin > Databases 选中目标库，直接点 Save changes（不做任何修改），可以重置 Metabase 到数据库的连接。Metabase 一般会在 10 分钟、20 分钟两次尝试关闭挂死的连接，但数据库不响应时，得从数据库侧手动断开。

更多细节可以参考官方的 数据库性能排障指南。

🛠️ 第三步：四件最常用的优化手段

瓶颈定位之后，下面四个方向覆盖了绝大多数场景，按投入从低到高排列。

3.1 给稳定的结果开缓存，把重复查询挡在数据库外

缓存的原理很直白：把上次查好的结果存下来，下次有人看同一个问题，直接返回存好的数据，不再让数据库重算一遍。如果你的数据一天只更新一次，一天查十次和查一次的成本差十倍。

• 在问题、仪表板、数据库三个层级都可以设置缓存失效策略：按时长失效（比如 1 小时后清缓存）、按调度失效（每小时/每天/每周/每月），或用自适应策略按查询平均耗时自动决定缓存多久。
• 数据更新频率低的问题优先开缓存，这是大表场景下收益最大的一招。

3.2 连接池按并发量配置，别让查询排队

连接池就是 Metabase 和数据库之间预先建好的一批"通道"，所有查询都得先抢到一条通道才能执行。用户一多、查询一并发，通道不够用，后面的请求就开始排队。

• 观察查询是否出现排队超时，参考 环境变量文档 中的MB_JDBC_DATA_WAREHOUSE_MAX_CONNECTION_POOL_SIZE（池子大小）和等待超时的相关项，按你的并发用户数逐步调大，每次调完观察排队是否消失。
• 同时治理源头：给跑批脚本加超时、挪到非高峰时段执行，或者直接让它们连一个数据库副本，别和线上查询抢通道。

3.3 修索引和列类型，减少数据库的"现场加工"

这条主要针对 1000 万行级别的聚合查询（5-15 秒区间内还能再压一压）：

• 给高频过滤、连接、聚合的字段建数据库索引，让扫描走索引而不是全表。
• 检查数字、日期、时间戳字段是否被存成了字符串。列类型不对时，Metabase 生成的查询会要求数据库在运行时逐行转换值，把列改成正确的类型并重新同步，能省掉这一步开销。
• 定期数据归档：把不再常用的老数据从主表挪走，控制表体量增长，这是维持 100 万行级别性能（2-5 秒复杂查询）不恶化的长期手段。

3.4 架构层手段：读写分离与数据分片

当单机数据库已经喂不饱负载时，往上加架构：

• 读写分离：把一部分查询流量引到从库，主库专注写入，Metabase 的只读分析流量是分离的典型受益方。
• 数据分片：按业务维度把数据打散到多个节点，避免单库容量和 I/O 成为天花板。
• 配合专用数据库服务器使用，Metabase 应用本身和数据库分开部署，互不抢资源。
• 另外注意一个容易被忽略的后台负载：Metabase 默认会定期做表和过滤值的同步扫描，大库场景下可以把它改成手动触发或调整周期，见 同步与扫描文档。

✅ 第四步：验证优化效果，别凭感觉收工

改完配置要留下证据，两个动作：

• 用使用分析看全局。使用分析 页面展示谁在跑什么查询、跑了多久，优化前后各截一次，慢查询的分布变化一目了然。

• 对比前后实测值。拿同一个 Question、同一时间段的响应时间和内存占用做前后对比：10 万行目标回到 200-500ms，100 万行复杂查询压回 2-5 秒，1000 万行聚合查询稳定在 5-15 秒内且不随并发恶化，就算达标。
• 官方还提供了 性能工具与使用分析文档、应用数据库配置文档，排查应用库侧（Metabase 自己的库，不是数据仓库）问题时对照使用。

📋 落地速查表

配置建议对照：10 万行用基础配置（1-2GB 内存）；100 万行给中等配置（2-4GB）；1000 万行以上按高级配置走（4-8GB 以上），并叠加缓存、索引、读写分离。Metabase 本身不挑数据规模，真正决定快慢的是数据库的承载能力和你的配置方式。

【免费下载链接】metabaseThe easy-to-use open source Business Intelligence and Embedded Analytics tool that lets everyone work with data :bar_chart:项目地址: https://gitcode.com/GitHub_Trending/me/metabase