一张 5 亿条数据的表，命中索引后扫描 1~10 行数据，请问在命中索引的情况下查询消耗时长大概多少？

[sun1993]

RT ，表会按照 userId 、resourceId 来查询（ userId 、resourceId 存在一个联合索引），查询 qps 在 100 以内，每次按照 userId 和 resourceId 查询到的数据一般在 10 条以内。

这张表目前 1 亿数据量，查询速度 150ms 以内，以现在的插入速度，明年中旬可能就会膨胀至 5 亿左右，那个时候同样的查询大概会比现在慢多少？ mysql 版本是 5.7 的。

这期间我们打算用分布式数据库来承接这部分的业务了，但需要时间，我担心还没来得及迁移这张表就先撑不住了。

[CEBBCAT]

（声明：DB 业余） 100M 到 500M ，单从数据量上感觉也没多多少，对于 MySQL 内部了解不是很多，基于之前的 B 树知识，我想查询时间可能不会有多少区别。至于别的地方有没有硬性限制就不知道了

但说起来单表数据这么多，倒是比较少见，特别是这个时间，150ms ，慢出天际了哥们儿😄

不知道是不是和索引有关，硬件配置怎么样？还是说用的是云 DB ？关于怎么科学优化，看楼下说说吧

[NotLongNil]

应该是 InnoDB 吧？如果能匹配中索引，那么查询速度的关键就是看索引的 B+ 树的有多少层

[NotLongNil]

B+ 树多一层，就代表多一次 IO 查询，你可以先算出现在每一次 IO 查询的速度，然后算出 5 亿数据的树层数，也就能大概推断出 5 亿数据的查询速度了

[sun1993]

@CEBBCAT 大部分查询都在 100ms 以下，我主要是怕切分布式数据库之间没缓冲时间。。接盘的老系统，细想下 mysql 索引原理其实也感觉没啥，但是没经历过这么大数据量的单表，多少还是有点慌😂

[sun1993]

@NotLongNil 嗯嗯，好的，谢谢，这张表查询 qps 倒不算高，还是多从库负载均衡查询，只要不超过 300ms 感觉都有缓冲的余地😂，反正后面也要迁到分布式数据库了，就怕这期间扛不住崩掉

[NotLongNil]

@sun1993 #5 你们该不会因为这张表就要迁移到分布式数据库吧？

[sun1993]

@NotLongNil 不是，是本来就就要慢慢把用户级的表迁移到分布式库的，我这个算是其中一个

[mark2025]

1. 分表试试
2. 迁移到 pg 数据库。如果是 SSD 磁盘，结果 10 条左右，我觉得查询应该在 50ms 内

分布式数据库是不是伪需求？
https://pigsty.cc/zh/blog/db/distributive-bullshit/

[sun1993]

@mark2025 分表会增大代码的复杂度，而且之后也不排除表数据量会爆表的可能，如果迁移到分布式数据库可以一劳永逸，那也是值得的。。我在之前的公司用过 TiDB ，现在这家公司还没确定用哪种分布式数据库，但在我来之前就已经立项要搞了

[june4]

才扫 10 行，又是 100qps 以内，这还有什么好担心的，几百亿都没事

[zzmark06]

已知：索引直接命中，直接出 10 行，查询速度 150ms
你得检查下索引命中情况了，150ms 听着是有 SCAN 的速度

后续表数据量上涨：基于网传 2000w 分表原理，多一层 tree ，实际差距大概是 ms 级的，也就是误差不足 1%，且打满 4 层以前速度不会变。

查询 qps 在 100 左右，索引抽 10 行，这种负载堆到 10 亿也没啥