最近在 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) 分布式扫描大量数据，速度非常快。因为查询相对较少，所以维护索引的成本要高得多。
除非你从一开始就知道会搜索数亿条记录，否则请考虑从简单扫描开始，并仅在性能难以接受时添加索引。即使这样，在查询较少且变化较大的情况下，在摄入时间而不是查询时间方面做些改进可能效果更好。
💡 你可以访问官网，免费注册云账号，立即体验 Bytebase。
556
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
