查看原文
其他

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

BB仔 Bytebase 2023-07-28
作者| Jeff Kaufman
原文链接|https://www.jefftk.com/p/you-dont-always-need-indexes
最近在 HN 上看到一个帖子:全表扫描优于建索引的情况 (https://news.ycombinator.com/item?id=36071397),看了一下作者原文 ,还挺有趣的,分享给大家。
有时为了方便快速搜索大量数据,一种方法是建立索引进行预处理,这样搜索只需要查看一小部分数据。然而,值得建立索引的门槛可能比你想象的要高。以下是我经历过的全表扫描反而更好的案例:
  • 十年前我为一个小型计费服务编写了一个内部通信应用程序。消息存储在 MySQL 中,如果全表搜索变慢或者遇到负载问题的时候,我就会添加索引;但即使有 10 年的消息需要搜索,在没有安装和维护 Sphinx(当时 MySQL 还不支持 InnoDB FULLTEXT 索引,v5.6 之后才加上)情况下它还是能保持响应。
  • 我最近发现有人维护了一个 0.5GB 的全文索引来搜索他 shell 历史记录中 100k 个命令 (https://news.ycombinator.com/item?id=35840944)。我在平面文件上用 `grep`,测试了一下,现在查询我 180k 历史条目需要 200ms (https://www.jefftk.com/p/logging-shell-history-in-zsh)。
  • 我的 contra 舞蹈搜索工具 (https://www.trycontra.com/) 根据查询对每个舞蹈进行排名,并且没有地理空间索引,因为其实只有 ~350 个舞蹈。
  • 我最近工作的时候会用一个病毒计数浏览器 (https://www.jefftk.com/mgs-counts/) 来实时检索人类病毒分类树,用 JS 的 includes 命令扫描约 15k 名称几乎就跟你打字速度一样快。
  • 我在广告业 (小编注:作者曾在 Google Ads 上班:https://www.jefftk.com/p/why-i-work-on-ads) 工作时,我经常需要使用生产日志来调试问题,并使用 Dremel (Melnik 2010: https://research.google/pubs/pub36632.pdf, Melnik 2020: https://research.google/pubs/pub49489.pdf) 分布式扫描大量数据,速度非常快。因为查询相对较少,所以维护索引的成本要高得多。
除非你从一开始就知道会搜索数亿条记录,否则请考虑从简单扫描开始,并仅在性能难以接受时添加索引。即使这样,在查询较少且变化较大的情况下,在摄入时间而不是查询时间方面做些改进可能效果更好。

Bytebase VS Archery
Star History 月度开源精选|2023 年 4 月
Bytebase 2.1.0 - 支持通过工单审批管控查询和导出权限
数据库 Schema 变更工具进化史

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存