如果id分布均匀，那就按照uid hash分表，没什么问题，查询用户加入过哪些群也很简单。查询群有多少人报名就要用UNION去查了。如果仅仅是想查多少人报名，比较容易解决：

• 可以改下表的设计，在群表加入一个用户数的字段也可以解决问题， 查询的时候直接查群表就好了；

• 或者采用redis的计数器来存群人数。

当然，还是还有一个问题没法解决，就是如果你想查群成员列表，还是得用UNION去查了。

我也想知道怎么解决，题主如果有解决方案了，麻烦分享一下。多谢。

推荐使用hash方式分表，根据用户id进行hash分表，假设你有1亿的聊天记录，那么不到100张表也够了。

建议按照用户ID分表。群应该是动态变化的（用户可以申请建群），分表的难度比较大。
查询群有哪些用户，建议在群的表里面增加冗余字段，保存用户列表的信息，只有查询用户详情的时候才关联用户表。

另外像@qinjianxiang所说，如果确认数据量在百万级别，从数据库性能看还没有到必须分表的地步。

我觉得是不是改动一下群表，把用户队列值写进去:'1,2,3' 然后成员表按用户id范围分一下表
不然的话你两个操作都要效率高 我觉得有点矛盾啊

查询哪个人加入过哪个群 查询群有多少人报名

需求就是这个，如果要提高查询速度，思路肯定是空间换时间。
加入过和报名人数应该是不完全一样的
建议建两个关联关系表

建立两个关联表来统计，报名表和用户加群表。

推荐使用hash方式分表，根据用户id进行hash分表

专门用一个表存储 用户ID 和 群ID 的映射关系。
这两个ID都是整数（int或者bigint），单表几千万行都可以的。

数据库前还可以加个缓存，按人，按群都可以缓存，不仅是缓存映射关系，还缓存群名称、人在群里的昵称等数据。

分表能解决一部分性能问题，但会带来应用开发上的困难。如果能确定数据在百万行规模，不需要分库分表。