学生点完提交，立刻打开报告，却看到「暂无结果」或一片空白，过几秒刷新又正常了。这种「刚交卷看不到报告」的短暂现象，在普查高峰期尤其常见，也最容易被当成故障上报。多数时候它不是数据丢了，而是读写分离带来的副本延迟。搞清楚它的来龙去脉，能省下大量本可避免的答疑和重测。
为什么会短暂看不到
为了扛住普查期间的并发，橙星云这类测评系统常把数据库拆成写库和读库：交卷这类写操作走主库，查看报告这类读操作走从库。这样一来，大量查询压力分散到多个从库上，主库只专心处理写入，整体才撑得住几千人同时交卷。代价是主库的数据要同步到从库需要极短的时间：主库先把变更写进 binlog，从库再拉过去回放，通常是毫秒到一两秒。如果学生交卷后立刻查询，请求正好落在还没回放完的从库上，就会读到「尚不存在」的旧状态，于是看到无结果。并发越高，从库回放越容易跟不上写入，这个窗口偶尔会被拉长。
这不是数据丢失
关键要分清：数据已经写进主库，只是从库还没追上。副本延迟是同步过程中的正常中间态，而不是答卷没保存。等回放完成，报告就会正常出现，交卷记录也不会丢。把这一点讲清楚，能避免学生和老师误以为答卷没交成功而重复作答，反而产生重复数据，给后续统计和报告生成添乱。想真正区分是延迟还是丢失，运维侧可以看主从复制延迟的监控指标：延迟在正常区间内就是同步没跟上，只有主库都查不到记录，才需要按故障处理。
前端该怎么提示
既然是短暂延迟，产品侧的处理比数据库调优更直接。刚交卷那一次查询可以强制读主库，也就是常说的读己所写，绕开延迟；或者在报告页做几秒的轮询重试，配一句「报告生成中，请稍候」的提示，而不是直接甩出无结果。两种方式还能叠加：先走一次主库拿到确认，再让后续查询回到从库分担压力。也可以按用户维度设一个几秒的粘滞窗口，让同一名学生在刚交卷那段时间里的查询都固定读主库，窗口一过再回到从库，兼顾一致和分流。对使用者来说，看到的是交卷后稍等片刻报告就出来，而不是空白页加反复刷新。至于延迟多久算超标、什么时候该告警，运维可以给主从延迟设一个阈值，超过就自动提醒，而不是等用户找上门才发现同步掉了队。这样既保住了读写分离在高并发下的性能，又不让人被短暂空窗吓到，是更划算的一种取舍。