随业务扩展，数据库表记录越来越多的优化思路？

[chillingkitten]

手头上有个 java 后台应用，是服务于各个业主的微信小程序的。 每个业主在微信平台上申请各自的 appId,appSecret 这些交给我们。

我们数据库里有个用户表，其中字段就有这个 appId,一开始为了快速上线，也没怎么长远考虑，直接单表走起。 基本上用 appId + openId 就能唯一定位到具体哪个业主下面的哪个用户。

查表的频率还是挺多的。 特别是新用户一来，就会根据 appId+openId 去检查是否已经落库，根据结果引导到后续不同的处理逻辑。 目前这个用户表的数据已经有 200W 左右了，而且搞商务的同事还在努力去拉新的业务，有潜在入驻的业主。 现在服务运行情况还好，数据库这块还不是瓶颈。 但如果再发展一两年，假设数据达到单表千万级，估计就很有问题了。

我想这种情况应该是个普适性的问题吧，就是这种多个“主体”的数据在一个单表里如何进行插入和查询的优化问题。 而且还有个特点是数据的不均匀性， 像我这个应用，目前小的业主下面只有 2W 左右数据，最大的一个业主下面就 100W 占了一半。

[yumenawei]

帮顶。期望其他大神给些方案。
我能想到的就是分表。

[springz]

大客户单独部署，另外推荐 TiDB 这种数据库，以后双管齐下就行了。做大了再说，TiDB 搭建一个最小可用拓扑阿里云也得每月 5w+ 了。

[jorneyr]

1. 不需要关联查询的大数据，可以放到 MongoDB
2. 需要关联查询，但是呢没啥复杂关系，可以拆开放到 MongoDB，从应用层获取后再到 MyQL 等关系型数据库查询
3. 难度大一些的可以考虑分库分表

[lithiumii]

微信 openid 本来就是全局 unique 的吧，不同的 appid，即使是同一个人，腾讯会给不同的 openid

[dustinth]

@lithiumii 不同商户 openid 不保证全局不重复的, 即使重复的概率很低.

很好奇 LZ 的业务场景, 应该不止一张用户表啊(除非是专门管客户信息的子系统), 其他业务表不用分表吗?

怎么分库分表不光是性能的需求, 还有业务的需求(比如要不要不同商户的数据隔离, 特别是大商户一般都会要求隔离).

保险的方法是按照商户分库分表(至少先做到按商户分表), spring JPA 对多商户其实支持挺好, 业务层的逻辑基本是透明的. 分析需求如果要合并表再备库到大数据平台做.

[lance6716]

@springz https://tidbcloud.com
欢迎免费试用 AWS/gcp 的 tidb 服务