如何将查询结果从View传递到Action？临时存储方案咨询

首先明确说：你的临时存储承载处理结果，再支持导出/保存的方案完全可行，这是Web系统里处理表单提交+结果留存+导出场景的常用思路，接下来我逐个拆解你的选项，再给你针对性建议：

1. 创建物理表副本作为存储载体 #

这个方案确实不够专业，问题很突出：

• 会产生大量冗余持久化数据，物理表会持续膨胀，还得额外做定时清理过期数据的机制，维护成本高
• 多用户并发时，必须加用户标识字段来隔离数据，不然很容易出现数据混淆
• 完全没必要用持久化物理表存临时结果，属于服务器资源的浪费

2. 创建临时表#tmptable作为原表副本 #

这是数据库层面的经典临时存储思路，但要注意核心的作用域问题：

• 本地临时表（#开头）的作用域仅限当前数据库连接，如果你是在单次请求内完成创建、处理、导出，那没问题；但如果是跨请求场景（比如用户提交表单后跳转到结果页，稍后再点击导出），Web系统通常是短连接，每次请求都是新的数据库连接，之前的临时表就不存在了，会直接报错。
• 如果坚持用这个方向，建议改用全局临时表（##开头），但全局临时表是所有用户共享的，必须加唯一标识（比如用户ID+请求GUID）来隔离数据，而且要用完就删，避免占用数据库资源。

3. 将数据存入DataTable并保存到Session #

这个方案的开销要看数据量：

• 如果处理结果是小数据集（几百条以内），完全没问题，Session存在服务器内存（或分布式缓存）里，开销几乎可以忽略，而且实现起来最简单
• 但如果是大数据集（上万条甚至更多），多用户并发时确实会占用大量服务器内存，可能导致性能下降
• 另外Session有过期时间限制，如果用户长时间不操作，结果会丢失，影响体验

4. 更优的替代方案 #

推荐两个更适配Web场景的方案：

方案A：带会话标识的物理临时表 #

结合方案2的思路优化：

• 用户提交表单时，生成一个唯一的session_guid（用GUID就行）
• 创建一个普通物理表，表结构里加session_guid、expire_time字段，把处理结果存入，同时设置过期时间（比如1小时）
• 结果页和导出接口通过session_guid查询对应数据
• 后台加定时任务，每天凌晨清理expire_time小于当前时间的过期数据
  这个方案解决了临时表的作用域问题，又避免了Session的内存开销，适合大多数常规场景。

方案B：序列化后存入分布式缓存（如Redis） #

• 处理完成后，把DataTable序列化成JSON或二进制数据，存入Redis并设置过期时间
• 结果页和导出接口从Redis取出数据反序列化使用
• 优势是性能极高，无需数据库操作，Redis会自动清理过期数据，适合高并发、大数据量的场景
• 注意如果是超大规模数据集（比如100万条以上），序列化和传输的开销会增加，这时还是推荐方案A

最终选型建议 #

• 小数据集、低并发：优先选Session存储DataTable，实现最简单
• 中等数据量、常规并发：优先选带会话标识的物理临时表，稳定可靠
• 大数据量、高并发：优先选Redis缓存存储序列化数据，性能最优

内容的提问来源于stack exchange，提问作者Massi