哪个更快,全表扫描还是建立索引?

最近在 HN 上看到一个帖子:全表扫描优于建索引的情况,看了一下作者原文 ,还挺有趣的,分享给大家。

有时为了方便快速搜索大量数据,一种方法是建立索引进行预处理,这样搜索只需要查看一小部分数据。然而,值得建立索引的门槛可能比你想象的要高。以下是我经历过的全表扫描反而更好的案例:

  • 十年前我为一个小型计费服务编写了一个内部通信应用程序。消息存储在 MySQL 中,如果全表搜索变慢或者遇到负载问题的时候,我就会添加索引;但即使有 10 年的消息需要搜索,在没有安装和维护 Sphinx(当时MySQL 还不支持 InnoDB FULLTEXT 索引,v5.6 之后才加上)情况下它还是能保持响应。
  • 我最近发现有人维护了一个 0.5GB 的全文索引来搜索他 shell 历史记录中 100k 个命令。我在平面文件上用 grep,测试了一下,现在查询我 180k 历史条目需要 200ms
  • 我的 contra 舞蹈搜索工具 根据查询对每个舞蹈进行排名,并且没有地理空间索引,因为其实只有 ~350 个舞蹈。
  • 我最近工作的时候会用一个病毒计数浏览器 来实时检索人类病毒分类树,用 JS 的 includes 命令扫描约 15k 名称几乎就跟你打字速度一样快。
  • 我在广告业 (小编注:作者曾在 Google Ads 上班) 工作时,我经常需要使用生产日志来调试问题,并使用 Dremel (Melnik 2010, Melnik 2020) 分布式扫描大量数据,速度非常快。因为查询相对较少,所以维护索引的成本要高得多。

除非你从一开始就知道会搜索数亿条记录,否则请考虑从简单扫描开始,并仅在性能难以接受时添加索引。即使这样,在查询较少且变化较大的情况下,在摄入时间而不是查询时间方面做些改进可能效果更好。


💡 你可以访问官网:https://www.bytebase.com/,免费注册云账号,立即体验 Bytebase。

作者:Bytebase原文地址:https://segmentfault.com/a/1190000043848825

%s 个评论

要回复文章请先登录注册