“阅后即焚数据库”并非真实存在的标准技术概念，而是对“零数据留存”目标的误称；其实现依赖应用层截断或TEE硬件隔离，而非数据库内置功能。
为什么不能直接用“阅后即焚数据库”这个概念
它不是现有数据库的内置功能，也不是某个开源项目的标准术语。你搜不到 fire-and-forget-db 或 ephemeral-sql-server 这类现成组件。所谓“零数据留存”，本质是控制数据生命周期：查询执行完、结果返回后，原始数据不落盘、不缓存、不记录、不审计——这和数据库设计目标天然冲突。
常见错误现象：SELECT * FROM users 执行后，你以为只拿了结果，其实数据库日志已写满磁盘，连接池缓存了执行计划，代理层还留着脱敏前的原始字段。
真实可行路径只有两条：
• 在应用层做数据流截断（查完即删临时表/内存表）
• 用可信执行环境（TEE）隔离查询过程，让数据库本身看不到明文
PostgreSQL + pg_cron + UNLOGGED 表的临时数据方案
适合内部审计、合规抽查等低频、单次、强隔离场景。核心思路是：把原始数据导入 UNLOGGED 表，查完立刻 DROP TABLE，跳过 WAL 日志，避免磁盘残留。
使用场景：
• 数据源来自一次性 CSV 导入
• 查询语句固定、不带复杂 JOIN 或函数计算
• 允许查询失败时不回滚（UNLOGGED 表崩溃即丢）
参数差异：
• UNLOGGED 表不写 WAL，但依然会进 shared_buffers 和 OS page cache
• 必须配 pg_cron 定时任务，在 NEXTVAL('seq') 后 5 分钟自动清理，否则人工漏删就破防
• 不支持 CREATE INDEX，全文检索或范围查询性能差
示例：
CREATE UNLOGGED TABLE tmp_query_20241105 AS SELECT * FROM raw_data WHERE ts > '2024-11-01';<br>SELECT COUNT(*) FROM tmp_query_20241105;<br>-- 然后立即触发 cron job DROP TABLE tmp_query_20241105;
SQLite in-memory 模式 + 应用层数据管道
适合前端工具、BI 插件、本地分析脚本这类终端直连场景。用 :memory: 数据库加载加密后的数据块，查完进程退出，内存自然释放。
容易踩的坑：
• sqlite3.connect(':memory:') 的每个连接都是独立实例，跨线程必须显式传参，否则查的是空库
• 加密数据解密必须在内存完成，不能先写临时文件再读——哪怕 /tmp 都算留存
• PRAGMA journal_mode = OFF 必须设，否则 SQLite 可能悄悄建 -journal 文件
性能影响：
• 数据 > 500MB 时，sqlite3 初始化变慢，且无法并行读取
• 不支持服务端预编译语句，每次 execute() 都要重解析 SQL
TEE 方案中 SGX 与 Keystone 的实际落地差异
如果你真有硬件级“零留存”需求（比如金融风控模型跑在客户数据上），别碰软件模拟。现在只有两类可商用 TEE 路径：
• Intel SGX：依赖 CPU 支持，需用 sgx-lkl 或 Open Enclave 包装 PostgreSQL，但 libpq 的 SSL 握手会在 enclave 外发生，密钥可能泄露
• RISC-V Keystone：更干净，整个 DB 进 enclave，但目前只支持轻量级 sqlite3 或自研引擎，pg_dump、VACUUM 这类运维命令全不可用
关键限制：
• 所有输入数据必须经远程证明（attestation）后才解密进 enclave
• 输出结果若要回传，必须走 oe_encrypt() 封装，否则内存 dump 可提取明文
• 没有日志、没有监控、没有慢查询分析——出问题只能靠 enclave 内打 printf
事情说清了就结束：所谓“阅后即焚”，烧的是控制权，不是技术名词。你得先决定谁信得过——是应用代码、内核、CPU，还是连自己都不信，只敢信硬件门禁。
