乐趣区

关于数据库:哪个更快全表扫描还是建立索引

最近在 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。

退出移动版