共计 752 个字符，预计需要花费 2 分钟才能阅读完成。
最近在 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。
正文完
