浏览器会话端处理800MB+非持久化CSV数据方案咨询

完全可行。
你碰到的不刷新页面无法删库、修改objectStore的问题，属于典型的用法错误，不是IndexedDB本身的能力限制。IndexedDB虽然默认是持久化设计，但完全支持在页面会话生命周期内按需创建、清空、删除数据库，不需要刷新页面。
它的核心优势刚好匹配你的需求：存储数据落在磁盘而非JS运行时堆内存，单域名存储上限通常可达数GB到数十GB（取决于用户磁盘剩余空间），不会出现直接把数据塞JS变量导致的堆内存溢出崩溃问题；自带索引、游标查询能力，不需要把全量数据加载到内存就能完成过滤操作。
你之前遇到的删库失败，99%的原因是删库时还有未关闭的活跃数据库连接占用资源，只要提前释放所有连接，删库、改库操作都能正常执行。

• 解析阶段不要全量读入内存：搭配基于Web Streams API的流式CSV解析器逐块读取本地文件，每解析出1000-5000条数据就批量写入IndexedDB，不要等整个800MB文件全量解析完再一次性写入，从源头避免解析阶段内存爆掉。
• 正确处理库的更新/删除逻辑：不要每次加载新文件就换库名，固定使用同一个库名即可。加载新文件前，先把当前页面持有的所有该库的连接实例逐个调用db.close()释放，再触发版本升级逻辑——直接升级数据库版本号，在onupgradeneeded回调里删掉旧的objectStore，创建适配新CSV列结构的新objectStore和对应索引，比反复删库稳定性更高。
• 适配动态列名场景：不要给每一列单独建objectStore，所有行数据存在同一个固定的objectStore里，用自增ID作为主键，每行直接存解析出来的原始对象即可。用户选择要过滤的列时，再临时给对应列创建索引，不需要的索引可以随时删除，减少不必要的存储开销。
• 查询阶段控制内存占用：做过滤操作时不要用getAll()一次性拉取所有匹配结果，用IDBCursor游标分批遍历，每次只取当前需要渲染/处理的批次数据（比如表格可视区只展示100条就先取100条，滚动加载时再继续读游标），避免查询阶段把大量数据拉进JS内存导致崩溃。
• 避免无用磁盘占用：监听页面的beforeunload事件，用户关闭/离开页面前主动清空或删除当前使用的数据库，不要把临时处理的数据长期存在用户本地。

• OPFS（源私有文件系统）+ 流式处理：这是浏览器专门提供的高性能本地文件读写API，数据存在域名专属的私有存储区，读写性能比IndexedDB更高，支持随机读写、流式访问。你可以把解析后的CSV按行分块存成二进制格式，过滤时逐块读取处理，内存占用可以压到几十MB级别，处理GB级文件都很稳定。
• Web Worker + 分块二进制存储：把CSV解析、过滤逻辑全部放到Web Worker里跑，避免阻塞主线程。解析后的数据拆分成固定大小的ArrayBuffer块存储，利用Web Worker的外部内存空间（不占JS主堆内存，上限远高于主线程堆限制），维护固定大小的内存池，只把当前需要处理/渲染的数据块加载到内存，内存利用率比存普通JS对象高很多。
• Wasm版嵌入式数据库：把SQLite这类轻量数据库编译为WebAssembly跑在浏览器里，支持直接导入CSV、通过SQL语句完成过滤聚合等操作，Wasm内存可手动管理，内存利用率和查询性能都优于原生IndexedDB，不需要持久化时可以开启纯内存模式，处理完直接销毁实例即可。

注意：不要考虑LocalStorage、SessionStorage这类存储方案，这类方案存储上限仅几MB到十几MB，完全无法支撑800MB级的数据处理需求。

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