结论：刷新应由真实需求触发
经营看板并不是刷新越频繁越好。持续扫描所有看板和数据表，会把数据库连接、计算资源和后台任务消耗在无人查看的内容上。更合理的策略是按业务时效分层：实时监控使用事件或短周期更新，日常经营看板在打开或明确请求时刷新，历史复盘则按批次更新。
AskTable 产品代码近期把看板和数据表刷新改为懒触发，并移除依赖定时扫描游标的路径，同时补充恢复任务和并发测试。BI0 的经营分析基于同一产品底座，这项工程变化体现的是资源使用从“系统猜测何时需要”转向“用户或业务事件明确触发”。
定时扫描的隐性成本
当看板数量增加时，每隔几分钟扫描一次会产生大量“检查后无需更新”的任务。数据库连接池、队列和缓存都要承受额外压力；多个租户在相同时间点触发，还可能形成尖峰。更麻烦的是，用户很难区分页面显示的是刚刷新结果、排队结果还是上一次缓存。
盲目提高频率也不等于数据更实时。如果上游 ERP 每天只同步一次，下游每分钟刷新只是重复读取旧数据。刷新策略应从业务新鲜度倒推，先问“最晚何时必须看到变化”，再决定同步和查询机制。
按需刷新需要哪些保护
首先要做并发合并：同一对象正在刷新时，后续请求应复用任务或排队，而不是重复计算。其次要有明确状态：未刷新、刷新中、成功、失败和结果时间都应可见。第三要有失败恢复：任务中断后可以安全重试，且旧结果不会被半成品覆盖。第四要设置查询超时，避免一个慢数据源占满工作线程。
对于公共分享页和多人看板，还要定义谁可以触发刷新以及频率上限。按需不等于无限请求。可以用短时间缓存、幂等任务键和租户配额保护系统，同时保留管理员强制刷新和故障排查入口。
如何验收刷新机制
准备冷门、热门和慢查询三类看板。观察无人访问时是否仍产生任务；多人同时打开热门看板时是否合并刷新；慢查询超时后旧结果是否仍可用；任务恢复后时间戳和数据版本是否正确。还要核对上游数据更新时间，避免把“页面已刷新”误解成“源数据已更新”。
业务指标可关注平均等待时间、重复任务比例、失败恢复时间和后台资源下降，而不是只看刷新次数。按需刷新适合多数经营看板，但设备告警、交易风控等实时场景仍应使用流式或事件驱动架构。
事实边界
本文基于 2026-07-25 的 AskTable 看板/数据表懒触发代码变更及配套测试撰写。具体刷新策略、缓存时长和可配置范围以产品实际版本为准，不把底层优化扩大为所有场景的实时性承诺。