大规模文本搜索性能瓶颈源于字符串查找算法的线性或平方级时间复杂度，如bf为o(n×m)，kmp/bm为o(n)，仍需全量扫描；根本解法是构建倒排、向量或fst等索引，将查询降至o(1)或o(log n)。

字符串查找算法的时间复杂度，直接暴露了大规模文本搜索为什么“一上量就崩”。不是模型不行，而是底层查找逻辑在数据翻倍时，耗时也跟着翻倍甚至更糟。

暴力匹配（BF）：O(n×m) 是最真实的压力源

比如用 Python 的 str.find() 或正则逐行扫描一个 10GB 日志文件找关键词，本质就是对每个位置尝试比对整个模式串。若文本长 n、模式长 m，最坏要比较 n×m 次。100 万行日志 × 平均每行 200 字符 × 模式长 10 → 超 20 亿次比对。CPU 白天黑夜都在干这个，用户还没点完查询键，服务已超时。

优化算法只能缓解，不能根除规模矛盾

像 KMP、BM、Sunday 这类经典算法，把时间复杂度降到 O(n)，看似飞跃——但注意：这里的 n 是文本总长度（字符数），不是文档条数。10GB 纯文本 ≈ 100 亿字符。O(n) 意味着仍要扫完全部字符，只是跳过部分比较。单机磁盘 I/O 本身就成了瓶颈，内存带宽也扛不住连续读取。

真正卡住大规模搜索的，是“查一次就得扫全量”的结构惯性

只要算法设计默认“必须遍历所有可能位置”，就无法应对百万文档、TB 级语料的实时响应需求。这不是调参或换库能解决的，而是必须跳出字符串层面，进入索引层：

• 倒排索引让“找含‘故障’的文档”变成查哈希表，O(1) 定位文档 ID 列表
• HNSW 把“找语义最像的段落”变成图上跳跃，跳过 99% 向量距离计算
• FST 压缩词典 + 跳表加速，让千万级词汇的前缀匹配仍保持微秒级

所以别只盯着“哪个字符串算法更快”

面对大规模文本，关键不是选 BF 还是 KMP，而是问：能不能不查字符串？

• 能建索引的，先建倒排或向量索引，把 O(n) 变成 O(log n) 或 O(1)
• 无法预建索引的流式场景，用 Aho-Corasick 多模式一次扫描，避免重复遍历
• 内存不够时，用 mmap 映射文件，让 OS 页面调度代替手动读块，减少拷贝开销