自己原文公众号： https://mp.weixin.qq.com/s/G4LJ6Eg1RoosmPKG6Om_hw

从前，乃至现在我依然会听到很多人说，当数据量大了以后就查询慢了。还有被问过“我数据表1000万记录左右，查询很慢怎么办？”。还有说这么大的量，需要大数据来处理。

      对于以上的问题我似乎觉得都不是问题。因为我觉得数据量大和查询关系不大，因为你并不需要全部查，你需要的只是数据量很大中的一部分或者是很少一部分。比如在百度中搜索 中山公园，你希望得到的就是中山公园，连北海公园都不希望看到，更不要说把百度所有的数据展现在你眼前。不需要。所以说数据量大和查询快慢没有关系。就像自由落体一样，和物体的重量无关。除非你查询就是全量，那自然是随着数据量多而变得慢，但是通常我们不需要这样，就像你不需要百度的全部数据，如果全部返回我估计几年都不够用。

     其次1000万记录根本不算大，我以前一个表动辄几十亿或者上百亿，我都没觉得大。依然很快。

     同样我没觉得100亿就大了，听说腾讯的微信团队，一天数据量就一万亿。在没有hadoop之前四大行和三大运营商不活了吗？他们哪个公司用户体量小于一亿？

背景：练习环境低配虚机未做任何优化措施。

结论：只要用到索引和分页在千万级（其实上亿数据也一样）不管Oracle MySQL都不慢。

但是如果不用的话，那就怪不得数据库了。就会出现常见的问题。

以上都是随便一些测试，不带有行业或者业务场景。而且实际环境的数据应该比这个更快一些。因为测试的机器性能不好。而不用索引的数据可能比我这个还要差，因为诗句的数据量不可能只有10G左右，都是几十GB甚至上百GB的。

请合理设计和使用索引，就像穿上秋裤是对冬天起码的尊重，使用索引是对数据库起码的尊重。

然后你就会发现和数据量几乎无关系。这是由于索引层级所决定的。2000万和2亿可能或者就是都是在一个层级。日后我们专门来说。今天先做个铺垫。