收到您的反馈，我联系研发排查下，稍后回复哈
您好，该问题已在 2025/06/17 17:00左右恢复，截图是今天触发的吗？
不是今天触发的，触发时间在2025-6-16 15：49左右
那问题应该不存在了，您可以再关注下，有问题再反馈
好谢谢
收到，我们排查一下，稍后回复您。
您好，我们核查了一下，物料筛选不稳定一般是有人在进行大批量修改物料时产生，但这个也是比较临时性的，如果您再遇到可以过一会再进行尝试。
您好就是我们在进行二次开发的时候嗲用了这个接口，要是不稳定的话这条数据的操作无法正常执行下去。后续这个问题有什么解决方案嘛？
您好，因为我们物料修改是异步操作，所以当公有云上同时存在大量的物料变更时，就会产生队列会有一定的延迟（一般最多几分钟），所以还是建议过一会再尝试，如果想彻底解决就是换到私有云或本地部署了。
就算是异步操作，读取的物料都不是一个物料，查询的数据和修改的数据都不是同一行，并不会相互影响。而且为了解决这个问题，要直接上本地部署，就不合理欸。而且这个sass软件，不做分库分表吗？为什么其他用户的操作会影响这个用户的使用呢？
请问这个有什么好的解决方案吗？
就算是异步操作，读取的物料都不是一个物料，查询的数据和修改的数据都不是同一行，并不会相互影响。而且为了解决这个问题，要直接上本地部署，就不合理欸。而且这个sass软件，不做分库分表吗？为什么其他用户的操作会影响这个用户的使用呢？
您好，非常理解您对稳定性的担忧，在我们系统里是有做分库分表的。但在大规模并发场景下(物料更新时，同时会去更新每个表单的物料信息)，为了保障系统稳定和数据最终一致性，会使用消息队列去异步处理，所以偶发会有短暂处理延迟。同时我们技术团队也在持续优化队列处理逻辑，以降低这种影响。
如果做到了分库分表，为什么会被其他租户的操作影响呢？
请问这是你们开发同事给的回复吗