首先明确说：这个方案是可行的——临时表确实能隔离单个用户的答题数据，考试结束后删除也能避免冗余数据占用存储空间，逻辑上是通顺的。不过从生产环境的稳定性、扩展性角度来看，这个方案存在一些可以优化的点，而且有更合适的实现方式。

原方案的潜在问题 #

• 数据库开销过高：创建/删除表属于DDL操作，比插入、更新数据的DML操作重得多。如果同时有大量用户启动考试，频繁执行DDL可能会导致数据库锁表，影响整体性能。
• 数据丢失风险：如果用户考试过程中遇到网络中断、浏览器崩溃等异常，临时表里的答题记录可能无法被正常处理，用户大概率需要重新答题，体验很差。
• 扩展性不足：如果后续需要做功能迭代（比如支持断点续考、统计用户错题分布、分析考试完成时长），原方案因为考完就删数据，完全无法支撑这些需求。

更优的实现方案推荐 #

1. 持久化答题记录表（最推荐，适合绝大多数场景） #

创建一张专门的user_answers表，把用户的答题记录持久化存储，用状态字段标记考试是否完成。典型的表结构可以设计成这样：

CREATE TABLE user_answers (
    id INT AUTO_INCREMENT PRIMARY KEY,
    user_id INT NOT NULL,
    exam_id INT NOT NULL,
    question_id INT NOT NULL,
    selected_option VARCHAR(10) NOT NULL, -- 存储用户选的选项，比如"A"/"B"
    submit_time DATETIME DEFAULT CURRENT_TIMESTAMP,
    status ENUM('in_progress', 'completed') DEFAULT 'in_progress', -- 标记考试状态
    -- 加唯一索引避免同一用户同一考试重复提交同一题目
    UNIQUE KEY idx_user_exam_question (user_id, exam_id, question_id)
);

这种方案的优势非常明显：

• 用轻量的DML操作（插入/更新）替代DDL，数据库压力小，并发支持更好。
• 天然支持断点续考：用户重新进入考试时，通过user_id+exam_id+status='in_progress'就能找回之前的答题记录。
• 留存的数据可以用于后续的数据分析，比如统计哪道题错误率最高、用户平均答题时长等。
• 清理数据更灵活：可以通过定时任务（比如每天凌晨）自动删除超过30天的已完成考试记录，或者归档到历史表，不用考完立刻删。

2. 会话级临时表（如果坚持用临时表） #

如果还是想使用临时表，建议用数据库原生的会话级临时表（比如MySQL的CREATE TEMPORARY TABLE、PostgreSQL的CREATE TEMP TABLE）。这种临时表只在当前数据库会话中存在，会话结束后会自动删除，不需要手动执行DROP TABLE操作。

好处是：

• 不用手动管理表的生命周期，减少出错概率。
• 会话隔离，不同用户的临时表互相独立，不会冲突。

但要注意：如果你的后端用了数据库连接池，需要确保用户的整个考试过程绑定同一个数据库会话（否则临时表可能提前被销毁）；另外，同样存在异常情况下数据丢失的问题，也无法留存数据做分析。

3. 前端暂存+一次性提交（适合短时长、小规模考试） #

对于一些时长很短（比如10分钟以内）、用户量不大的简单考试，可以把用户的答题数据先存在前端（比如localStorage或者sessionStorage），等用户点击提交时，一次性把所有答案发送到后端，后端直接计算分数并返回结果，不需要存储中间记录。

这种方案的优势是完全不需要数据库存储中间数据，实现简单；但缺点也很明显：前端存储有大小限制，用户清除缓存或浏览器崩溃会丢失所有答题记录，而且无法支持断点续考。

总结 #

如果你的系统需要支持并发考试、断点续考，或者未来有数据分析的需求，持久化答题记录表是最优选择；如果只是临时搭建一个简单的小考试，会话级临时表或前端暂存方案可以考虑，但原方案的普通临时表创建/删除方式不推荐——DDL操作的开销实在太大，很容易在用户量上来后出问题。

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