Androidx-Room多用户存储方案选型：按用户分库还是单库加用户标识列

方案一：按用户创建独立数据库（命名规则如myappname_$userId） #

优点 #

• 数据天然完全隔离，不存在因为SQL漏写过滤条件导致的跨用户数据泄露风险，安全性更高
• 单库体积小，单用户的查询、增删操作效率更高；如果需要删除某用户的所有数据，直接删除对应的数据库文件即可，不需要逐表批量删除，操作成本极低
• 支持对不同用户的数据库做独立配置，比如独立加密密钥、独立缓存策略，更适配隐私合规类需求
• schema升级逻辑统一，所有用户的数据库自动复用同一套升级流程，不需要额外兼容用户标识相关的逻辑

缺点 #

• 用户切换时需要重新初始化Room实例，首次登录新用户时如果涉及数据库升级会有轻微的耗时，对切换速度有极小幅影响
• 如果存在跨用户的公共数据，需要额外维护一个公共数据库实例，会小幅提升架构复杂度
• 需要自行封装数据库实例管理逻辑，按userId缓存已创建的Room实例，避免重复创建实例导致的内存浪费或性能问题
• 数据库文件数量会随登录过的用户数增加而增长，不过单设备登录用户数通常不会超过10个，这个问题基本可以忽略

方案二：单库所有表新增用户标识列，查询时过滤userId #

优点 #

• 全程只需要维护一个Room实例，用户切换时不需要做数据库切换操作，登录登出流程更简单
• 公共数据和用户私有数据可以存在同一个库，不需要多实例管理，架构更轻量
• 需要做全局数据统计、跨用户批量操作时更方便，不需要遍历多个数据库文件

缺点 #

• 存在数据泄露隐患：即使通过Room自动填充、DAO层统一封装等方式降低漏写过滤条件的概率，只要有一处查询/更新/删除操作漏加WHERE COL_USER_ID = :userId条件，就会出现跨用户数据误操作的问题，故障影响面大、排查成本高
• 用户数据清理成本高：注销用户时需要逐表删除对应用户的所有记录，表越多操作耗时越长，还容易出现数据残留
• 单库体积会随登录用户数增加而变大，单表数据量上升后索引、查询性能会有一定下降
• schema升级时需要强制新增表都带用户标识列，存在疏漏风险；如果后续需要支持单用户数据独立加密、导出备份等功能，实现难度极高

• 优先选择方案一的场景：
  • 用户数据隐私要求高，不允许出现跨用户数据泄露
  • 单用户数据量较大，或者存在用户注销需要清理全部数据的需求
  • 后续可能需要支持单用户数据独立加密、导出备份等功能
  • 单设备登录过的用户数不会特别多（常规场景下10个以内完全无压力）
• 优先选择方案二的场景：
  • 单用户数据量极小，同设备登录过的用户数最多不超过3个
  • 业务存在高频跨用户数据查询、统计的需求
  • 用户切换频率极高，对切换耗时要求极苛刻
  • 开发资源有限，不想投入成本做多数据库实例管理

内容的提问来源于stack exchange，提问作者Sourav Kannantha B