内网 BI 提速：从 10 秒到秒开

定位：用户不会说「架构慢」，只会说「怎么又要等」

这套内网数据分析平台的数据规模：主数据物化表约 220 万行、54 列，数据源是集团系统每晚同步。功能上线后收到的第一条真实反馈不是「功能不全」，而是「每次第一次点开几个页面都要过几秒才有反应」。速度就是可用性——这篇写它怎么从「过几秒」走到「秒开」，以及为什么最后发现快是两层的事。

数据层：让查询本身变快

第一刀：把 JOIN 变成物化。最初查询是运行时四表 JOIN，用户每点一次都付一次连接成本。改成每晚定时重建物化表：源表校验行数门槛（不足则拒绝重建，保留旧数据）→ 后台生成新表 → 校验通过后原子换名。查询从「四表联查」变成「单表扫描」，重建 13 分钟换走每次查询的几秒。

第二刀：把远端数据搬近。部分场景的数据在飞书多维表格，首次读取要过公网 API。预热任务每天把热数据拉回本地缓存，冷数据才回源——用户感知的「没缓存」从「白屏等 API」变成「几乎不存在」。

第三刀：让大结果分批走。明细查询不再一次返回全量，服务端分页、行数守卫（超限直接拒绝并提示缩小范围），大表查询恒定在可预期的耗时内。

交互层：让等待「感觉」变短

数据层做完还有残余等待——公网源、复杂聚合。这一层的结论很朴素：消除不了的就把它变成进度。

• 流式查询：查询接口改 SSE，服务端算完一批推一批，前端表格边查边长，首行数据在整表完成前就能看到；
• 骨架先行：点击导航先立刻渲染页面框架，数据异步填充——「没反应」和「在加载」是两种完全不同的体感；
• 进度条与拦截：大表加载挂进度条；筛选候选值超过一千个的维度不再生成下拉（渲染比查询更慢），表头悬浮提示「请使用检索」——把最慢的路径直接从产品里拿掉。

一条反直觉的取舍

优化过程中最有效的动作之一，是删功能：把「所有字段都能当筛选项」改成「高频字段做筛选、长尾字段走检索」。工程直觉总想给用户更多入口，但每个下拉的候选值列表都要一次 distinct 查询——入口越多，首屏越慢。速度优化做到深处，是产品取舍，不是技术炫技。

价值与可复用方法

复盘下来是两条线各三刀：数据层物化、预热、分批；交互层流式、骨架、拦截。顺序很重要——先数据层后交互层，否则会在错误的层面优化：把一个 8 秒的查询做成带进度条的 8 秒，用户照样走人。

可复用的最小集：物化表 + 行数门槛守卫、热数据预热、SSE 流式返回、骨架屏先出框架、超限路径直接拿掉。五件事没有一件新潮，但内网工具的口碑就是由「点一下就出」堆出来的。