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