自助 BI 一多人就卡：Metabase 的瓶颈在结果集不在 CPU

早上九点的转圈现场：CPU 很闲，页面很慢

早上九点整，三十几个人几乎同时点开同一个「昨日经营看板」。浏览器里十二张卡片一起灰着，左上角一直在转圈，最快的那张卡三十几秒后才亮，最慢的那张最后直接变成一行错误提示。有人刷新了一次，情况更糟；有人关掉重开，只是让队列又多排了一个人。

运维的第一反应是看 CPU。BI 应用服务器那条 CPU 曲线几乎是平的，连一半都没到；目标数据库的 CPU 也不高，慢查询日志里干干净净，一条超过阈值的语句都没有。内存看着还有富余，磁盘 IO 也没有明显抖动。所有「看起来该背锅」的资源都很闲，但用户就是打不开页面。

真正卡住的位置不在 CPU 上：应用服务器到目标库的连接池被打满了，几十个查询排在等待队列里；同时有几条查询已经在执行，它们返回的结果集宽而长，正在把应用服务器的出网带宽和堆内存一起吃掉。也就是说，这个系统的算力在等活干，而活卡在了「能不能拿到连接」和「结果集搬得动搬不动」这两件事上。

自助式 BI（Metabase、Apache Superset 这一类）部署在自有服务器上，人一多就慢，绝大多数情况下就是这个形态。加 CPU 是最顺手的动作，也是最没有针对性的一步。真正需要建模的是这条链：并发查询数 × 单个查询的结果集大小 × 数据库连接池上限 × 结果缓存命中率。这四个变量里，只有一部分和 CPU 有关。

一次提问在服务端发生了什么：从浏览器到目标库 SQL 的完整链路

要算清楚容量，得先知道一次「提问」在服务端到底走了几步。浏览器发给 BI 应用的不是一条 SQL，而是一个问题标识加一组参数，比如「问题 1427，日期范围昨天，区域华东」。后面所有的事都发生在服务端。

第一步是读元数据库。BI 应用要先把这个问题的定义取出来：它基于哪个数据源、用了哪张表、有哪些字段、聚合方式是什么、图表类型是什么。同时还要取当前用户的权限信息：能不能访问这个数据源、能不能看这个数据集、行级过滤规则是什么。这一步会打出若干条轻量查询，单条很便宜，但频率极高，而且它是每次打开看板都要走一遍的。

第二步是把问题翻译成目标库能执行的 SQL。Metabase 内部用的是一套自己的查询表示（通常被叫作 MBQL），Superset 则是从图表的查询上下文生成 SQL；两者都会在最后落到目标库的方言上。权限过滤通常会直接写进这条 SQL 里，所以同一个问题在不同用户手里生成的语句可能并不相同——这一点后面会直接影响缓存命中率。

第三步是从连接池里取一条连接。取不到就排队，这是整条链上最容易被忽略、也最容易在高并发时成为主瓶颈的一环。拿到连接之后，语句才发往目标库执行。

第四步是结果集回程。目标库返回的结果先进入 BI 服务端，在内存或临时缓存层里停留、排序、序列化成 JSON，再通过网络回到浏览器。这一步的资源占用和查询本身有多复杂几乎无关，只和结果集有多大有关。

把四步摊开看，一次提问的总耗时构成是这样的：元数据读取 + 等待连接 + 目标库执行 + 结果集传输与序列化 + 浏览器渲染。CPU 主要出现在「目标库执行」和「序列化」这两段里，剩下的三段——尤其是等待连接和结果集传输——基本不消耗 CPU。这就是为什么「CPU 很闲而页面很慢」不仅可能，而且是常态。

看板不是一次查询而是一批：刷新放大倍数这个概念

容量建模里最容易算错的一件事，是把「一个用户」当成「一个查询」。实际上用户打开的是一个看板，而一个看板是 N 张卡片，每张卡片背后是一个问题，每个问题是一条 SQL。刷新一次看板，发出去的是一批并发查询，不是一个。

这里需要引入一个明确的量：刷新放大倍数。它约等于「单看板卡片数 × 每张卡片依赖的问题数」。一张卡片看起来是一个图，但它可能由多个问题组合而成（比如一个对比图叠了两个指标），所以卡片数和问题数不是一比一。如果一个看板有 12 张卡片、平均每张依赖 1.5 个问题，那么刷新一次就产生 18 条查询。

再乘上同时刷新的人数。假设早高峰有 40 个人在两分钟内打开同一个看板，那就是 40 × 18 = 720 条查询几乎同时涌向连接池和目标库。这个数字不是 benchmark，是一个纯算术的演算结果，用来说明量级关系；真实值取决于你们自己的看板复杂度、缓存命中率和实际高峰人数，必须以自有压测为准。

自动刷新会把这个数再抬一层。如果看板设了每 5 分钟自动刷新，那么它在后台会以固定周期持续产生一批查询，和人工打开的那一批叠加。刷新周期越短，稳态并发越高。

还有一个容易被误判的现象：卡片是「一张一张亮起来」的，很多人会以为是数据库在慢慢跑。实际上浏览器对同一个域名的并发连接数是有限的，超出的请求会在浏览器侧排队；服务端的连接池排队和浏览器侧的连接排队会同时存在，表现都是卡片逐张出现。所以「逐张亮」既可能是服务端排队，也可能只是前端连接数限制，判断要靠服务端指标而不是肉眼。

结论很直接：容量模型里的并发单位不是「用户数」，而是「同时进行中的刷新动作数 × 看板卡片数」。用人数去做容量估算，误差可以差出一个数量级。

结果集才是内存与网络的主账：行数 × 列宽，而不是查询复杂度

这一节是整篇文章的核心。结果集的体积大致等于行数 × 每行的字节数，而每行的字节数又等于各列的平均宽度之和。也就是说，一条返回 30 万行、每行 40 列的明细查询，和一条返回 50 行、每行 3 列的聚合查询，对这条链的压力差了几个数量级——即使前者在数据库里只是走了一个覆盖索引、执行得飞快。

所以「查询复杂」和「查询昂贵」是两件事。一条带多层子查询、条件复杂的语句，如果最终只聚合出十几行，它对 BI 这条链的压力很小；一条最简单的明细拉取，如果没设行数上限，可能直接把应用服务器打爆。这就是为什么看慢查询日志解决不了问题：慢查询日志只反映执行耗时，不反映结果集体积。

结果集的体积会在三个地方同时记账。第一处是应用服务器的内存。同时持有的结果集数量乘以单个结果集的体积，就是堆内存峰值；如果 BI 在应用层做排序、二次聚合或格式化，中间态还会再放大一截。第二处是应用服务器的出网带宽，结果集要从这里走到浏览器，大结果集会在高峰时把网卡打满，表现为所有人的页面一起变慢。第三处是浏览器，一个几十兆的 JSON 在前端解析和渲染，用户感受到的是「页面卡死」，而这时候服务端可能已经闲下来了。

列宽这件事尤其容易被低估。宽表是自助 BI 的典型产物：业务人员拖字段的时候不会考虑传输成本，一张明细表几十个字段全选是很常见的。同样的行数，40 列和 5 列的传输与内存成本差很多倍。长文本字段、未裁剪的时间戳、被保留的高精度小数，都会悄悄把行宽推上去。

判断方法也很明确：不要只看「查询耗时」这一个指标，要额外采集三个分布——单条查询的返回行数（看 P95 而不看平均值，因为平均值会被大量小查询稀释）、单条响应的字节数、以及高峰时段的出网带宽峰值。这三个数字出来之后，结果集是不是主账，一眼就能看出来。具体的分布区间因业务而异，需以自有监控数据为准。

连接池是双向的：应用侧池上限与目标库连接上限要一起算

连接池这件事必须当成同一个瓶颈的两面来算，只算一面一定会出问题。

第一面是应用侧。BI 服务端维护到每个数据源的连接池，池上限直接决定同时能跑几条查询。池满了，新查询进入等待队列，用户看到的就是转圈。

第二面是目标库侧。数据库有全局的连接上限，所有客户端共享。BI 是典型的长连接、突发并发型客户端：即使没有查询在跑，它也会保持一定数量的连接；一旦高峰来了，连接需求瞬间抬升。这种形态对读库很不友好，很容易在几分钟内把连接占满，而连接被占满之后，受影响的不仅是 BI，连后端业务的正常读请求也会开始变慢。

真正有效的并发上限是这两者的较小值：min(应用侧池上限, 目标库侧分配给 BI 的可用连接数)。很多团队只调了前者，把池上限从很小调到很大，结果不是变快，而是把目标库压垮——因为限制被解除了，涌入的查询变多了，而库侧的真实能力没有变。

还有一个反直觉的点值得单独说：增加 BI 应用实例会让库侧连接消耗线性上升。两台实例就是两套连接池，四台就是四套。如果目标库的连接预算没有同步重算，横向扩容的结果是把库打满，页面反而更慢。所以加实例之前，第一件事不是装机器，是把连接账重新算一遍。

估算方法可以用变量表达：先确定目标库侧能给 BI 的可用连接配额（总上限减去其他消费者的常驻占用，包括后端服务、ETL、数据同步、运维工具、其他 BI 入口），再用这个配额除以「单个看板刷新占用连接数」，得到的就是系统能同时承载的刷新动作数。把它和早高峰的实际刷新人数对比，排队系数就出来了。整个过程里没有一个固定常数，都是需要你自己填的变量。

读写分离的部署里，通常会让 BI 走只读实例。这时候要注意，只读实例的连接上限同样要纳入这份预算，而且主从延迟会让「刚写入的数据查不到」变成另一类问题——那是数据新鲜度问题，不是容量问题，但用户的感受是一样的：看板上的数不对。

排队的表现为什么是「转圈」而不是「报错」

连接池打满之后，查询不是失败，而是等待。请求进入等待队列，前端保持长连接，浏览器上只有一个转圈动画。这是自助 BI 最典型的故障外观，也是最容易被误判为「数据库慢」的原因。

等下去有两种结局。一种是在超时之前等到了连接，查询正常执行，用户的感受是「慢，但最后出来了」。另一种是超过了等待上限或查询超时，应用层抛出一个超时异常，浏览器上变成一张报错卡片或者一片空白。无论哪种，数据库那边都没有对应的错误——因为语句压根没发过去，或者发过去了但被应用层主动取消了。

这就解释了一个很常见的排查困境：慢查询日志是空的，数据库监控上看不到任何异常，但用户投诉如潮。这时候「日志空」本身就是最强的线索，它说明瓶颈在执行之前。正确的做法是把注意力移到应用层的指标上：等待连接的线程数、连接池的活跃数与等待队列长度、查询超时次数、平均排队时长。

排队还有一个特性值得记住：一旦并发超过了池上限，系统吞吐就不再随人数增长，多余的负载只会拉长队列。吞吐曲线会进入平台期，而延迟曲线会陡峭上升。所以早高峰的体验往往不是「稍微慢一点」，而是从某个临界点开始急剧恶化——九点零几分还能用，九点十分就全都转圈了。这个临界点对应的并发数，就是你们真正需要写进容量文档里的那个数。

区分排队与执行慢的方法很简单：如果增加并发时「查询执行耗时」基本不变而「端到端响应时间」快速上升，那是排队；如果两者同步上升，那是目标库侧的执行压力。这两个数字在同一个监控面板上就能看出来，不需要额外工具。

缓存命中率为什么上不去：缓存键与参数的关系

结果缓存是自助 BI 最有效的减压手段，命中时直接跳过目标库执行，连连接池都不用占。但很多团队上了缓存之后命中率依然很低，问题基本都出在缓存键上。

缓存键的构成通常与「问题定义 + 参数 + 数据源」相关，具体的键构成规则需要以你们实际使用的版本文档为准。这里的关键推论是：参数不同的同类提问不会共享缓存。一个筛选了「昨天、华东」的问题，和一个筛选了「昨天、华南」的问题，是两个键；一个筛选了「近 7 天」，一个筛选了「近 30 天」，又是两个键。

打散键的因素比想象的多。日期范围是最常见的一个：如果每个人进来默认看到的日期范围不同（比如按各自上次访问的时间回填），那么同一批人打开同一个看板会产生几十种参数组合，命中率被稀释到接近于零。自由输入的筛选框也是杀手，用户随手输入的任何取值都会生成新键。行级权限同样会参与，因为权限过滤写进了 SQL，不同权限的人生成的语句不同，缓存自然不能共用。

第二类是 TTL 与刷新节奏不匹配。缓存的过期时间短于看板的自动刷新周期，等于每次刷新都必然未命中，缓存白设；反过来，如果底层数据的更新周期远长于 TTL，那就是过度失效，白白浪费了本可以复用的结果。正确的做法是把 TTL 对齐到数据的实际更新节奏：每小时刷新的中间表，TTL 就按小时量级设；每天更新一次的汇总表，TTL 可以按天量级设。

第三类是缓存容量被结果集体积吃掉。缓存能放多少条，等于缓存可用空间除以单条结果集的体积。结果集越大，能缓存的条目数越少，淘汰越快，命中率越低。这是一个很硬的耦合：不控制结果集大小，缓存扩容的收益会被迅速抵消。

第四类是部署形态。如果结果缓存放在应用进程内存里，那么多实例部署时每台机器各存一份，同一个请求落到不同实例就会未命中，命中率按实例数被稀释，而且大结果集还会加剧 GC 压力。把结果缓存外置到共享缓存服务，可以让多实例共享同一份缓存，命中率不再随实例数下降——代价是多了一个需要单独算容量、单独做高可用的组件。具体支持哪些缓存后端、如何配置，需以实际版本文档为准。

提升命中率的动作是有先后顺序的：先收敛参数（把自由输入改成下拉枚举、把日期范围固定成几个档位），再对齐 TTL 与数据更新节奏，然后才是考虑缓存容量与共享缓存。直接跳过去加缓存容量，通常是花了钱却看不到效果。命中率也要分层看，按看板、按问题分别统计，一个总数字会掩盖掉「核心看板命中率很高、长尾看板几乎为零」这种真实分布。

元数据库这个被忽略的单点

几乎所有容量讨论都集中在目标库，而元数据库——那个存放看板定义、问题定义、数据源连接信息、用户与权限的小型数据库——几乎没人给它算过账。

元数据库的负载特征是高频、轻量、不可省略。每次打开看板都要读一遍问题定义和权限，一个 12 卡的看板会打出一批元数据小查询。单条很便宜，但乘上人数和刷新频率之后，总量并不小。更麻烦的是它的连接池通常配置得很小，因为「平时够用」；一旦被打满，用户看到的现象是「看板打不开」或者「内部错误」，而目标数据库一切正常，排查方向很容易被带偏。

元数据库还是典型单点依赖。它挂了，看板定义读不出来，用户权限读不出来，查询历史也读不出来——即使目标库健康、应用进程健康，整个 BI 平台也是不可用的。这是最容易被忽略的可用性短板：大家花力气给目标库做主从、给应用做多实例，唯独元数据库是单台裸跑。

该做的事不复杂：独立部署，不和别的应用共用；独立核算连接预算并留出余量；配上主从与定期备份，并且验证过恢复流程；把连接数、慢查询、磁盘增长纳入监控。还有一项容易漏：查询历史与审计表会持续膨胀，如果不做定期清理，元数据库会越跑越慢，最终在某个早晨突然成为瓶颈。清理策略与保留周期需要结合你们自己的审计要求确定。

典型场景一：50–200 人看板的资源画像

以下为典型部署思路，并非特指某一真实客户。这一节给的是一套建模方法，不是一组可以直接照抄的数字。

用户侧画像：50 到 200 名业务人员，自己拖拽查询，不写 SQL。看板数量在几十个量级，单个看板 8 到 20 张卡片。访问高度集中在两个时段——上午九点到九点十五，下午两点前后；看板普遍设置了 5 到 15 分钟的自动刷新。

把容量拆成变量。设高峰同时刷新人数为 P，人均同时打开的看板数为 D，单看板平均卡片数为 C，单卡平均依赖问题数为 Q，缓存命中率为 h，那么高峰期的并发查询需求约为 P × D × C × Q × (1 − h)。再设应用侧有效连接池上限为 K，排队系数就是这个需求与 K 的比值。当比值持续大于 1，系统就进入了平台期。

结果集这一本账另算：并发查询数乘以单条结果集的平均体积，就是应用服务器的内存峰值压力；同一时刻的出网流量峰值，则决定了带宽是否成为新瓶颈。注意这两个峰值都要按高峰时段取，按全天平均算会严重低估。

部署形态上的建议顺序是这样的：应用侧至少两个实例做高可用，但加实例之前先把目标库的连接预算重算一遍（两个实例就是两套池）；元数据库独立部署并配主从与备份；目标库用只读实例承接 BI 查询，把 BI 的突发并发和主库的在线业务隔离开；结果缓存尽量用共享缓存，避免多实例各自缓存导致命中率稀释。

高峰治理属于成本最低的一类手段。把默认看板收窄到核心卡片，非核心卡片改为手动刷新；按部门把自动刷新周期错开，避免所有人落在同一分钟；给明细类问题设行数上限；把「导出全部明细」这类需求从交互式看板上剥离出去，改到后台任务里跑。注意，这里讨论的是交互式查询，不是批量导出任务——两者对资源的要求完全不同，导出任务应该走独立的执行通道和独立的连接配额，混在一起只会互相拖累。

这个场景里所有具体数值都需要以你们自己的压测结果替换。压测方法也有讲究：应该回放真实的看板刷新动作、按真实的参数分布发起，而不是拿单条 SQL 去压——单条 SQL 的压测结果和真实高峰表现之间几乎没有相关性。

典型场景二：跨数据源拼接的看板

以下为典型部署思路，并非特指某一真实客户。这类场景在自助 BI 里越来越常见，也是最容易把容量模型做崩的一种。

业务诉求很朴素：一张表里同时看业务库的订单数和数据仓库里的渠道成本，业务人员希望拖一下就能对比。实现上通常有两条路。一条是在 BI 侧做跨源关联，前提是中间有统一的查询引擎能把两个源拉到一起——具体是否支持、支持到什么程度，需以实际版本文档为准。另一条是在上游先把两个源的数据落进同一张中间表，BI 只查一个源。

第一条路的问题在于它会把两条瓶颈链串起来。两个数据源各有各的连接池、各有各的响应特征，整体的响应时间由慢的那一个决定，而连接占用是两边同时发生。更关键的是，如果关联是在应用层完成的，那么两个结果集都要先搬回应用内存，内存占用是两个结果集体积之和，而且通常还要额外加上关联操作的中间态。这种情况下，应用服务器的内存会比单源场景高出一截，出网压力倒可能下降（因为最终只返回一个结果集），资源画像和单源完全不同。

第二条路更稳，代价是要在上游做数据工程。物化中间表或者预聚合表把跨源关联提前算好，BI 侧退化成一次普通单源查询，连接池、结果集、缓存三项压力同时下降。这也是为什么在自助 BI 的语境里，真正有效的优化往往发生在 BI 之外。

跨源场景还有一类问题必须提前处理，它比性能更致命：口径。两个源的时间字段粒度是否一致、时区是否统一、去重口径是否相同、维度取值是否对齐——这些没对齐，跑得再快也是错的，而且错得很隐蔽，因为图能画出来、数看着也合理。所以跨源看板的验收顺序应该是先对口径、再谈性能。

优化顺序：先限流与行数上限，再缓存，再预聚合

优化动作是有明确顺序的，顺序错了会花很多钱却看不到效果。判断依据只有一个：当前的主要矛盾在哪一层。

第一层是限流与上限。包括查询超时时间、单条查询最大返回行数、单个看板的卡片数上限、按用户或按数据源的并发配额。这些改动几乎不需要改业务逻辑，风险低，见效快，而且它们的作用是给系统装上一个「最坏情况的天花板」——即使后面几层都没做，系统也不会崩，只会慢。唯一要确认的是行数上限会不会影响明细类场景的业务可用性，这需要和业务方对齐，不能拍脑袋设。

第二层是缓存。动作包括收敛参数取值、对齐 TTL 与数据更新节奏、把结果缓存外置为共享缓存。做完之后要看的不是「有没有配缓存」，而是命中率的实际数字，并且按看板和按问题分层看。如果命中率依然很低，说明瓶颈在参数维度或 TTL 设置上，继续加缓存容量没有意义。

第三层是预聚合与物化中间表。这一层改变的是数据形态，收益最大，但改动成本也最高，需要上游数据链路配合，还要处理刷新调度、失败重跑、口径一致性。它适合用在那些被反复查询、逻辑固定、数据量大的核心指标上，不适合用在长尾的探索性查询上。

第四层才是加规格与加实例。什么时候轮到它？判断条件很明确：前面三层都做到位了，监控上显示排队队列为空、结果集体积已经受控、缓存命中率处在合理水平，而 CPU 依然是饱和的。只有在这种情况下，算力才是第一约束。而且加应用实例之前必须先做一件事——把目标库侧的连接预算重新算一遍，确认新增的连接池不会把库打满。

这套顺序反过来走是很多团队踩过的坑：一上来就扩容，容量问题被推迟但没有消失，人数再涨一轮，同样的故障在更高的配置上重演一遍。

把上面四层按顺序走一遍之前，建议先填一张瓶颈项对照表。这张表的作用不是给配置，而是把「症状」翻译成「该改哪个变量」，避免一上来就扩容。每一行的最后一列是复测项，改完之后必须回到这一列去看有没有真的动。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。

自助 BI 的选型与扩容顺序

选型与扩容阶段，真正需要逐项确认的是下面这些条目，而不是「要几核几 G」。

• 应用实例数量，以及每个实例到每个数据源的连接池上限；两者相乘就是打到库侧的连接总量。
• 结果缓存的存放位置：进程内存还是共享缓存服务；共享缓存需要单独算容量与高可用。
• 元数据库的部署形态：是否独立、是否有主从、备份与恢复是否演练过、历史表是否有清理策略。
• 目标库侧的连接预算分配：BI 分到多少，其他消费者各占多少，是否用只读实例隔离 BI 的突发并发。
• 出网带宽：按高峰时段的结果集传输峰值估算，而不是按平均流量。
• 监控指标清单：连接池使用率与等待队列长度、平均排队时长、查询超时次数、单查询返回行数的 P95、响应体大小的 P95、缓存命中率（分层）、元库连接数、出网带宽峰值、浏览器端渲染耗时。
• 压测方案：回放真实看板刷新动作，覆盖真实参数分布与真实高峰人数，而不是单条 SQL 压测。

硬件规格与报价这一项不展开：不同规模的平台差异很大，且机型与带宽随供给变化，需以官网实时信息为准或实时询价。把上面这份清单逐项填完，规格自然就推导出来了，反过来先定规格再填清单，通常会选偏。

关于自助 BI 的容量账，上线前最该算清楚的几项

把全文收拢成一份上线前必须填完的清单，每一项都是变量关系，没有可以直接套用的常数。

• 高峰同时刷新人数，以及人均同时打开的看板数；这两个数决定了并发的起点。
• 单看板卡片数与单卡依赖问题数；它们决定刷新放大倍数，是「用户数」到「查询数」之间的换算系数。
• 单条查询返回行数的 P95 与响应体大小的 P95；这两个数决定结果集这本账，也是内存与带宽估算的输入。
• 应用侧连接池上限与目标库侧分配给 BI 的可用连接配额；取两者的较小值才是有效并发上限。
• 缓存键涉及的参数维度数量，以及 TTL 与底层数据更新周期的对齐关系；这决定命中率的上限。
• 元数据库的部署形态、连接预算与备份恢复能力；这是最容易被漏掉的单点。
• 高峰时段的出网带宽峰值；它常常在 CPU 和内存都没问题的时候先到顶。

每一项都要用自有压测和监控数据复核。填完之后，你会得到三个数：系统在进入平台期之前能承载多少并发刷新、结果集这条链上的峰值压力有多大、以及当前缓存能抵消掉其中多少。这三个数就是自助 BI 的容量账本。

自助 BI 这篇的技术口径与来源，以及哪些需要你自己验证

本文对架构链路与机制的描述，基于 Metabase 与 Apache Superset 这类自助式 BI 的通用工作方式：浏览器到应用服务、应用元数据库、被分析的目标数据库这条三层结构；问题定义到目标库 SQL 的转换；结果集先进入服务端再返回浏览器；查询缓存命中时跳过目标库执行；应用层连接池与数据库侧连接上限的双向约束；异步与后台查询、物化中间表、查询超时与行数上限、错峰刷新等常见优化路径。这些都是原理性描述，用于建立容量模型，不指向任何具体版本的默认参数。

本文不提供任何实测数值：没有吞吐量 benchmark、没有响应时间实测、没有内存占用数值、没有默认参数值、没有版本号对照、没有客户案例与实测数据。文中出现的所有数字要么是可替换的变量符号，要么是基于变量关系的算术演算示例，用于说明量级关系，不可以直接当作容量结论使用。

需要你自己验证的部分，至少包括这几类。连接池的默认值与可配置项、查询缓存的键构成规则、支持的缓存后端与 TTL 配置方式、异步查询的触发条件与结果过期策略、跨数据源关联的支持范围、元数据库的备份与恢复流程——这些在不同版本之间可能有差异，需以实际版本文档为准。

容量类结论则必须以自有压测为准。压测应当回放真实的看板刷新动作、使用真实的参数分布、覆盖真实的高峰人数，并从应用层和数据库层同时采集指标；只压单条 SQL 或者只压应用接口，得到的结论都不能外推到真实高峰。文中两个典型场景均为部署思路演示，用于说明建模方法，并非特指某一真实客户。