我们计划在我们的web应用程序中实现一个功能，它将为用户提供搜索功能，并将db（mysql-innodb）中所有匹配记录的ID保存为“列表”。结果可能以百万计。我们希望用户能够保存多达100万个ID。它必须是实时的（最多5-10秒的延迟是可以接受的）。此列表随后可以作为另一个过滤器与现有过滤器组合使用。
我们不需要从客户端传递这些id，因为可以在服务器端执行相同的搜索来检索这些id。但是，以后不能重复使用相同的搜索来获取这些ID，因为搜索结果可能会更改。
我们有几千个活跃用户，不希望有很多人创建这么大的列表，但随着时间的推移，这些列表中保存的ID总数可以增加到数亿。
服务器的ram超过了整个数据库（几百GB）。它还使用ssd。
以下是我们需要解决的问题：

- Saving up to 1 million ids in DB (within few secs)
- Using these IDs as a search criteria with other filters (this additional criteria shouldn't slow down the searches by more than few secs)

这似乎是一些可能的解决方案：
解决方案1：
有一个单独的表，其中包含用户id、列表id和文档id
将ID另存一行（可能1个列表有100万行）
一定大小后的分区表
优点：这个表可以很容易地在以后的连接条件中使用，并且带有索引的搜索性能应该很快。
问题：插入会很慢-我知道有一些方法可以加快插入速度，但仍然需要几秒钟以上的时间，尤其是在表增长时。
解决方案2：
将所有ID保存在一行中
使用mapreduce等技术将这些ID作为参数在查询中分块传递，以实现快速搜索
优点：插入会很快。
问题：使用mapreduce可以提高搜索性能，但它会给服务器带来很大的负载，特别是当许多用户开始进行此类搜索时。
有什么建议是最好的方法吗？有没有其他可能的方法来迎合这种情况？