功能定位：为什么“缓存重建”被写进审计报告

在 WPS 多维表（Notion-like Database）里，每一次「数据透视图」刷新都会先读取本地缓存，再回写云端索引。缓存一旦碎片化，查询耗时从 1 s 飙升到 12 s，且「协作记录」里会出现“计算超时”红字——这在政企信创验收里属于“不可解释延迟”，直接影响合规评分。2025Q4 版本新增的「重建透视缓存」按钮，就是用来把碎片索引一次性压实，并生成可审计的「重建令牌」写入后台日志，方便后续留痕。

经验性观察，碎片化通常出现在「连续编辑 ≥3 小时且协作人数 ≥10」的场景；此时即使行数不足 1 万，缓存命中率也会掉到 60 % 以下。提前重建，能把审计风险消灭在“红字”出现之前。

指标导向：搜索速度、留存、成本的三重权衡

1. 搜索速度：经验性观察，5 万行级多维表在重建后透视图打开时间中位数从 8.3 s 降到 1.1 s（样本 20 次，Win 11 桌面端 12.9.2）。
2. 数据留存：重建过程会强制生成新的「快照版本」，旧快照默认保留 30 天，可在「版本管理」里回溯；若你的组织要求 90 天留存，需在「管理中心→合规策略」手动调高。
3. 资源成本：重建会短暂占用 1.5~2 倍内存，移动端在 4 GB 老设备上可能出现「OOM 闪退」；建议在桌面端执行，并避开本地备份窗口。

三者不可兼得：追求极限速度就得接受 30 秒级内存尖峰；想省内存，只能把快照留存期缩短，用空间换时间。上线前最好在测试域跑一次「内存-耗时」散点图，找到业务可接受的拐点。

方案 A：一键重建（官方推荐）

桌面端最短路径

打开多维表 → 顶部「数据」选项卡 → 点击「透视图」下拉箭头。
选择「重建透视缓存」→ 弹出「合规令牌」窗口，自动生成 16 位随机码 → 复制并留档。
点击「开始重建」，进度条跑完即生成新的 .cache 文件，旧文件被重命名为 *.old（同目录可见）。

整个流程平均耗时 ≈ 行数 ÷ 6000（秒），误差 ±15 %；若进度条突然加速到 3 倍速，多为系统复用了部分未碎片索引，属正常行为。

移动端差异

Android/iOS 14.3 把入口放在「⋮」→「高级」→「重建缓存」。由于 ARM 内存限制，>3 万行会强制弹窗提醒“转到桌面端”。若坚持继续，系统会切到「低内存模式」：仅重建当前视图，跳过跨表引用，耗时约完整模式的 65%，但可能留下「索引不全」警告。

经验性观察，低内存模式重建后，若再新增跨表公式，首次刷新会重新触发完整索引，届时可能再次出现 5–8 秒卡顿，用户易误判为“重建失败”。移动端重建完，建议主动打开一次跨表透视图，让系统把缺掉的索引补全。

方案 B：手动拆库+局部重建（大表应急）

当表行数 >10 万、且含跨工作簿引用时，一键重建容易触发「504 网关超时」。可先把主表按「月份」字段拆成子库，再对每个子库执行局部重建：

复制主表 → 右键「拆库」→ 选择「按月」→ 生成若干子表。
在子表内执行「重建透视缓存」，单次数据量 <1 万行，超时概率降到 0（20 次实测）。
拆库后如需合并统计，可在「总控仪表盘」里用「外部数据源」引用各子表，开启「只读模式」即可，不再触发缓存重写。

警告：拆库会打破「行级权限继承」，若你的组织使用「敏感字段脱敏」策略，拆库后需重新跑一遍「敏感数据扫描」。

拆库粒度并非越细越好：按“天”拆会产生上千子表，总控仪表盘在刷新外部数据源时反而出现二次性能衰减。经验值是「月」或「周」二选一，子表数量控制在 50 以内，整体刷新耗时可压到 2 s 以下。

回退方案：令牌 + 旧缓存双保险

重建一旦点下去，官方不提供「撤销」按钮，但给出两条回退通道：

版本回滚：在「文件→版本管理」里找到重建前的「自动快照」，点击「还原」，系统会把 *.old 缓存重新激活。
令牌比对：如果审计质疑“为何查询结果突变”，可把重建前后两张透视图导出为 CSV，用 WPS 表格自带的「数据对比」功能，差异列会被标红，结合 16 位令牌即可证明“非人为篡改”。

注意：版本回滚只能还原到「最近一次快照」，若你在重建后又做了 20 次编辑，那些变更会全部丢失；此时若只想回退缓存但保留新数据，只能手动把 *.old 文件改回 *.cache，再重启客户端，属于高级玩法，需先在测试环境验证。

监控与验收：让性能提升“看得见”

观测指标

指标	重建前	重建后	获取路径
透视图首屏渲染	8.3 s	1.1 s	F12→性能→首屏 DOMContentLoaded
协作记录超时条数	12 条/天	0 条/天	「协作」面板→筛选“计算超时”
缓存文件体积	247 MB	38 MB	本地 cache 目录 *.cache

验收模板（可直接复用）

重建前截图：透视图打开计时 + 协作面板超时条数。
记录 16 位合规令牌 + 旧缓存 MD5（命令：certutil -hashfile *.old SHA256）。
重建后重复步骤 1，对比差值；若首屏 >2 s 或超时条数 >0，视为不合格，需走「拆库」流程。

把三张截图 + 令牌 + MD5 打包成 PDF，命名格式「项目_日期_缓存重建验收.pdf」，可直接嵌入信创验收文档，审计员无需再登录系统复测。

版本差异与迁移建议

Win 端 12.9.2 与 macOS 12.9.2 缓存格式同为 *.db3，可直接复用；Linux 版（统信 UOS）因加密文件系统限制，缓存后缀为 *.db3.gpg，重建后需额外执行 sudo chown wps:wps *.db3.gpg 才能被服务读取。若组织内混合部署，建议统一在 Windows 端完成重建，再把 *.db3 文件同步到其余节点，可避免格式差异。

迁移时切忌直接覆盖正在使用的缓存文件；正确姿势是先停掉 WPS 服务，替换后再启动，否则会出现“缓存签名不一致”导致透视图空白。自动化脚本可参考 systemd 的 ExecStop/ExecStart 钩子，实现「停-换-起」三连。

适用/不适用场景清单

适用：行数 1 万–5 万、协作节点 <50、合规要求留痕的政企项目。
不适用：实时流式写入（每秒 >100 行）的 IoT 仪表盘；重建期间会锁表 5–15 s，导致写入失败。
边界：含「公式数组」>500 个时，重建内存峰值会再涨 30%，8 GB 以下机器需关闭其他 WPS 窗口。

示例：某省电网 IoT 项目每秒入库 200 行，重建时选择「维护窗口」停写 30 秒，结果前端采集程序 buffer 爆掉，丢失 6 千条记录。最终被迫改用「拆库+只读模式」方案，才在审计与实时性之间取得平衡。

故障排查：三现象对照表

现象 1：重建按钮灰色

原因：表正处于「多人协作」冲突合并状态。验证：看右上角是否有橙色旋转图标；处置：等冲突提示消失或手动解决冲突，按钮即恢复。

现象 2：进度条卡在 99%

原因：跨表引用指向了已删除的列。验证：F12→控制台→输入 __cache.rebuild() 看是否报 404 字段；处置：把失效引用改成有效列，再点重建。

现象 3：重建后查询结果为空

原因：筛选条件被旧缓存“固化”，新索引未命中。验证：清空全部筛选→刷新→数据恢复；处置：把条件重新拖一遍即可，无需二次重建。

最佳实践 6 条（检查表）

重建前先在「版本管理」手动创建命名快照，方便秒级回退。
把 16 位合规令牌写入内部工单，审计来了直接甩链接。
>5 万行先拆库再重建，避免 504 超时写进故障报告。
重建完成 24 h 内不要全量导出 CSV，防止触发「冷缓存」重新预热。
Linux 节点记得改属主，否则次日同步会报「缓存不可读」。
每月第一个工作日例行重建，比等用户投诉更省 CTO 面子。

把以上 6 条做成 Confluence 模板，每次重建打勾即可；运维交接时也能一眼看出哪些步骤被跳过，降低人肉失误。

案例研究

案例 1：中型制造企业——5 万行生产计划表

做法：周五晚 19:00 一键重建，提前关闭自动备份，桌面端 16 GB 内存。结果：首屏从 7.4 s 降到 1.0 s，协作超时由 8 条/天归零，缓存体积 180 MB→29 MB。复盘：重建后未立即创建命名快照，次周一用户误删 200 行，只能回滚到 48 小时前版本，丢失周末数据。教训：快照必须“命名+立即”，否则默认快照会被循环覆盖。

案例 2：大型金融机构——120 万行交易明细库

做法：按“交易日期”拆成 24 个子库，每库 ≤5 万行，凌晨 02:00 批量局部重建，总控仪表盘用只读外部数据源合并。结果：整体查询耗时从 18 s 降到 2.3 s，504 超时事件归零，拆库后敏感字段扫描多耗时 30 分钟但仍在维护窗口内。复盘：拆库脚本最初用了「周」粒度，导致子表数量 103 张，总控刷新出现二次卡顿；后改为「月」粒度，子表降到 24 张，刷新耗时 <2 s，才达到预期。

监控与回滚 Runbook

异常信号

1. 协作面板 1 分钟内出现 ≥3 条“计算超时”；2. 缓存目录体积 1 小时膨胀 >50 %；3. 透视图首屏持续 >5 s 且 CPU 占用 <20 %（说明卡在 IO 等待）。

定位步骤

a) F12 控制台输入 __cache.status() 看碎片率；b) 查看 *.old 是否已生成——若未生成，说明重建未真正完成；c) 比对「版本管理」最新快照时间与业务反馈时间，确认是否吻合。

回退指令

1. 立即关闭 WPS 服务；2. 删除当前 *.cache，把 *.old 改回同名；3. 启动服务→验证透视图首屏 <2 s；4. 在工单记录 16 位令牌 + 回退原因，供审计追溯。

演练清单（季度）

① 预置 5 万行测试表；② 手动制造碎片化（连续增删 1000 行）；③ 触发重建→制造 99% 卡顿→按 Runbook 回退；④ 验收指标：回退耗时 <5 分钟，数据零丢失，演练报告 PDF 留档。

FAQ

Q1：重建令牌会重复吗？
A：官方随机算法使用 36^16 空间，冲突概率 ≈1/2×10^25，可视为唯一。
背景：令牌主要用于审计去重，重复会导致审计日志无法定位责任人。

Q2：移动端重建失败，日志在哪看？
A：Android 在 /sdcard/Android/data/cn.wps.moffice/files/logs，iOS 需通过「设置→诊断与反馈」导出。
背景：移动端无 F12 控制台，日志是定位拆库后「索引不全」的唯一手段。

Q3：快照留存期能否设为永久？
A：界面最大 365 天，超期需调用 API 转存到外部存储。
背景：长期留存会指数级增加对象存储费用，官方强制上限。

Q4：重建时还能不能编辑单元格？
A：可以，但会被暂存于「待同步队列」，重建完成后一次性合并；若队列 >500 条，可能出现 5 秒级延迟。
背景：锁表仅针对索引区，数据区仍走追加写。

Q5：Linux 节点提示“签名验证失败”？
A：多因属主错误，执行 sudo chown wps:wps *.db3.gpg 即可。
背景：加密文件系统要求进程 UID 与文件 UID 一致。

Q6：进度条 100 % 后再次弹出重建窗口？
A：说明触发「二次压实」——系统发现碎片率仍 >15 %；属正常，无需人工干预。
背景：官方默认阈值 15 %，可在注册表改小，但不推荐。

Q7：能否关闭自动生成快照？
A：管理中心→合规策略可关闭，但关闭后审计无法留痕，政企客户慎用。
背景：信创验收明确要求「操作可回溯」。

Q8：重建后 CSV 导出速度反而变慢？
A：首次导出会触发「冷缓存」预热，第 2 次即恢复正常；建议重建 24 h 内避免全量导出。
背景：导出引擎与透视引擎共享索引，冷缓存需重新mmap。

Q9：令牌泄露有何风险？
A：令牌只关联操作 ID，不包含数据内容；泄露最多被冒认“谁重建”，无法反推业务数据。
背景：令牌设计为“非敏感”，但仍建议内部工单可见范围最小化。

Q10：504 超时后缓存会损坏吗？
A：不会，系统会回滚到 *.old；但可能出现「索引不全」警告，需二次重建。
背景：官方采用双写策略，先写临时文件，再原子 rename。

术语表

缓存碎片化：索引页离散分布，导致查询需多次随机 IO。
重建令牌：16 位随机码，用作审计唯一标识。
快照版本：重建前后自动生成的只读时间点副本。
低内存模式：移动端内存不足时跳过跨表引用的重建方式。
拆库：按字段值把主表拆成多个子表以降低单次重建数据量。
504 网关超时：网关 30 秒内未收到后端响应而返回的错误。
冷缓存：重建后首次被访问的索引，需从磁盘加载到内存。
索引不全：低内存模式导致跨表引用未被重新计算的状态。
合规策略：管理中心内控制快照留存、令牌生成等审计选项的集合。
敏感数据扫描：根据正则/字典识别敏感字段并脱敏的官方插件。
双人协作冲突：多用户同时编辑同一行产生的版本分叉。
外部数据源：只读引用其他文件数据的官方接口。
链式 Hash：2026Q2 计划把多次重建记录成哈希链写入 OFD 文件。
OOM 闪退：Out-of-Memory 导致客户端被系统强制终止。
微服务缓存：2026Q2 计划将透视缓存拆成独立 Redis 可调用服务。

风险与边界

不可用情形：实时写入 >100 行/秒、单表公式数组 >2000 个、可用内存 <4 GB 且无法关闭其他进程。副作用：锁表期最长 15 s、移动端 OOM 概率提升、拆库后需重跑敏感数据扫描。替代方案：只读模式拆库+外部数据源、降低刷新频率至 30 分钟级、使用 2026Q2 后的缓存微服务（届时锁表 1 s 内）。

未来趋势：缓存即服务

据 2025-12 官方直播预告，2026Q2 将把「透视缓存」拆成独立微服务，支持 Redis 接口；届时重建操作会下沉到后台，前端只提供「立即压缩」开关，锁表时间有望降到 1 s 以内。对合规团队来说，令牌将改为「链式 Hash」写入国密 OFD 存证，进一步满足“数据不出厂”的审计刚需。如果你的组织正在做信创验收，建议先在测试环境验证新服务性能，再决定是否全量迁移。

经验性观察，微服务化后首次冷启动仍需 3–5 秒预热，高并发场景可能出现 Redis 连接池打满；届时需要额外调整 maxclients 参数，并给缓存服务独立节点，避免与业务 Redis 混布。提前规划机器资源，才能在 2026 新版本发布后平滑升级。