Postgres存储用户任务多数据的高效实现方案选型咨询

结合你读高频、无删除、任务可调整的业务场景，最优选择是方案2

各方案问题梳理 #

• 方案1（预留10个任务列）：灵活性极差，后续任务超过10个就得改表结构，任务调整还要同步改业务代码适配字段，维护成本太高，直接排除。
• 方案3（Postgres数组存储）：强绑定PG数据库特性，以后要换数据库基本没法迁移，读出来还要解析数组才能拿到每个任务的状态，应用层处理麻烦，要统计某个任务的完成率之类的聚合查询性能也差，不推荐。
• 方案4（varchar拼接存储）：判断用户有没有完成某个任务还要先分割字符串再匹配，性能很低，也没法建索引做统计查询，很容易出拼接错误、匹配错任务的bug，直接排除。

方案2的优势完全匹配你的需求 #

你可以把方案2的表字段设为user_id（用户唯一标识）、task_id（任务唯一标识）、is_completed（布尔类型存完成状态），也可以按需加complete_time（完成时间）这类扩展字段，优势如下：

1. 读性能足够高：给user_id建索引后，一次查询就能拉到单个用户所有任务的完成状态，结果不用额外解析直接就能用，完全满足你登录后多次读取的要求，而且你这个场景没有删除操作，索引不会有碎片化问题，长期性能稳定。
2. 不用改表就能适配任务调整：后续要加新任务、改旧任务，完全不用动表结构，只需要改业务侧的任务配置就行，刚好匹配你说的近期任务可能调整的需求。
3. 扩展空间大：以后要加任务完成时间、任务触发入口这类属性，直接加字段就行，也支持统计单个任务完成率这类扩展需求。

额外优化小技巧：你可以在应用层给单用户的任务状态加个5分钟左右的短缓存，还能进一步降低数据库压力，读性能还能再提。

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