那就是业务上取舍了, 加上时间区间, 分区.

数据到底属于群组还是用户？你这 group_id 要跟随 user_group 变吗 这里 project.group_id 如果实际意义是 project.user_id 指向的用户的当前 group_id 的话，这属于冗余字段了 如果你能保证 project.group_id 是可信任的，直接 (user_id = xxx OR group_id in (xxx,xxx,xxx))，提前算好 group_id 列表就好了（可以放 redis 缓存里），层级结构总不至于有几千个成员吧

给方案 1 投一票，应用层在查 project 之前和之后，来做额外处理，db 只支持 id 简单查询就好了。userid/groupid 和创建时间各单独加个索引

@sagnitude 分两个是考虑用户可能离开了某个群组，但是希望他能看到自己的数据 (user_id = xxx OR group_id in (xxx,xxx,xxx)) 是可以的，只是说这里 SQL 查起来很慢，不知道怎么优化

使用 like path% 和 in (user_ids)哪个好得做测试，影响条件很多， 排序给 created_at 也加上索引试试

能不能把过滤逻辑放到 es 做，关键字段比如 created_at 、user_id 、xxx ，经过业务过滤出需要的结果集 id ，然后返回 id[]，直接库里根据 id 查数据，然后返回？

这种需求应该使用列存储数据库或者 es 解决。

要么按时间分区呗，要么冗余一张近一年的表，这种翻页列表数据一般不会翻到很后面，真翻到了可以接受稍微慢点。

mysql 的查询非常依赖索引，多条件查询对 mysql 是弱势，不能穷举所有的检索条件组合。

有同样的场景 来蹲个解决方案