这是一个创建于 32 天前的主题，其中的信息可能已经有所发展或是发生改变。
RT ，表会按照 userId 、resourceId 来查询（ userId 、resourceId 存在一个联合索引），查询 qps 在 100 以内，每次按照 userId 和 resourceId 查询到的数据一般在 10 条以内。
这张表目前 1 亿数据量，查询速度 150ms 以内，以现在的插入速度，明年中旬可能就会膨胀至 5 亿左右，那个时候同样的查询大概会比现在慢多少？ mysql 版本是 5.7 的。
这期间我们打算用分布式数据库来承接这部分的业务了，但需要时间，我担心还没来得及迁移这张表就先撑不住了。
11 条回复
 |
1
CEBBCAT 32 天前
（声明：DB 业余） 100M 到 500M ，单从数据量上感觉也没多多少，对于 MySQL 内部了解不是很多，基于之前的 B 树知识，我想查询时间可能不会有多少区别。至于别的地方有没有硬性限制就不知道了
但说起来单表数据这么多，倒是比较少见，特别是这个时间，150ms ，慢出天际了哥们儿😄 不知道是不是和索引有关，硬件配置怎么样？还是说用的是云 DB ？关于怎么科学优化，看楼下说说吧 |
 |
2
NotLongNil 32 天前
应该是 InnoDB 吧？如果能匹配中索引，那么查询速度的关键就是看索引的 B+ 树的有多少层
|
|
3
NotLongNil 32 天前
B+ 树多一层，就代表多一次 IO 查询，你可以先算出现在每一次 IO 查询的速度，然后算出 5 亿数据的树层数，也就能大概推断出 5 亿数据的查询速度了
|
 |
4
sun1993 OP @CEBBCAT 大部分查询都在 100ms 以下，我主要是怕切分布式数据库之间没缓冲时间。。接盘的老系统，细想下 mysql 索引原理其实也感觉没啥，但是没经历过这么大数据量的单表，多少还是有点慌😂
|
|
5
sun1993 OP @NotLongNil 嗯嗯，好的，谢谢，这张表查询 qps 倒不算高，还是多从库负载均衡查询，只要不超过 300ms 感觉都有缓冲的余地😂，反正后面也要迁到分布式数据库了，就怕这期间扛不住崩掉
|
|
6
NotLongNil 32 天前
@sun1993 #5 你们该不会因为这张表就要迁移到分布式数据库吧？
|
|
7
sun1993 OP @NotLongNil 不是，是本来就就要慢慢把用户级的表迁移到分布式库的，我这个算是其中一个
|
 |
8
mark2025 31 天前
1. 分表试试
2. 迁移到 pg 数据库。如果是 SSD 磁盘，结果 10 条左右，我觉得查询应该在 50ms 内 分布式数据库是不是伪需求？ https://pigsty.cc/zh/blog/db/distributive-bullshit/ |
|
9
sun1993 OP @mark2025 分表会增大代码的复杂度，而且之后也不排除表数据量会爆表的可能，如果迁移到分布式数据库可以一劳永逸，那也是值得的。。我在之前的公司用过 TiDB ，现在这家公司还没确定用哪种分布式数据库，但在我来之前就已经立项要搞了
|
 |
10
june4 31 天前
才扫 10 行，又是 100qps 以内，这还有什么好担心的，几百亿都没事
|
 |
11
zzmark06 30 天前
已知：索引直接命中，直接出 10 行，查询速度 150ms
你得检查下索引命中情况了，150ms 听着是有 SCAN 的速度 后续表数据量上涨：基于网传 2000w 分表原理，多一层 tree ，实际差距大概是 ms 级的，也就是误差不足 1%，且打满 4 层以前速度不会变。 查询 qps 在 100 左右，索引抽 10 行，这种负载堆到 10 亿也没啥 |
Select Language