看板变慢通常不是一个“性能参数”造成的，而是数据量、图表粒度、高基数字段、筛选器、表达式和数据源查询共同叠加的结果。先定位是哪一步慢，再决定是否需要改图表、改数据或改部署。
先用五个问题定位
- 慢在首次打开、切换筛选、图表联动，还是导出？
- 所有用户都慢，还是仅 Web 客户端、某个地区或某个数据范围慢？
- 慢的是概览页还是明细页？
- 问题出现前是否新增了字段、筛选器、页面、图表或数据源？
- 数据源查询、网络传输和图表呈现中，哪一段耗时最长？
第一优先级：降低首屏粒度
官方指南建议用聚合图表作为起点，把详细图表留给已经筛选的小范围数据。概览页应回答“哪里异常”，明细页才回答“具体是哪条记录”。不要在一个页面同时展示大量点、完整明细表和高基数字段标签。
第二优先级：检查筛选器与表达式
- 高唯一值字段优先使用列表框或文本筛选器，避免项目筛选器带来额外显示成本。
- 隐藏或删除不使用的筛选器；不要因“可能以后用”就自动创建大量筛选器。
- 文本区域中堆叠很多筛选器、计算标签或迷你图，也会让页面显得更迟缓。
- 对适用的表达式，优先在已聚合视图上计算，避免把复杂计算反复施加到明细行。
第三优先级：减少不必要的数据
导入前尽可能限制时间范围、字段和无效值。官方指南指出，从 SBDF 加载通常比 TXT 更快；“高而窄”的数据结构往往也更利于处理。对于外部数据源，先在数据库或连接视图缩小范围，避免把不需要的列和记录传到分析端。
数据库中分析的额外注意事项
使用外部数据时，标记、筛选和图表操作都可能触发查询。高基数、高复杂度图表和级联筛选会增加数据源负载。不要仅因为界面可操作就认为数据库一定承受得住；应在典型并发条件下观察查询时间和资源占用。
验证优化是否有效
每次只改一个变量，并记录打开时间、切换筛选时间、主要查询耗时、行数和用户体验。没有基线和对照，就无法判断“优化”只是感觉变快，还是真的消除了瓶颈。
结论
性能优化的目标不是删掉功能，而是把概览、下钻与明细分层。让每一次查询和每一个图表都服务于明确的问题，通常比增加硬件更先见效。
Spotfire 企业落地进阶教程