SQL数据库全文索引创建及PostgreSQL全文索引模块相关问题咨询

首先明确一个常见认知偏差：你提到的PostgreSQL现有内置文本搜索是“启发式非完整全文索引”的判断并不准确，当前版本PostgreSQL基于tsvector+GIN的全文检索实现就是标准的全量倒排索引结构，反而是你提到的旧contrib/fulltextindex模块是功能残缺的早期实验性原型。以下针对你的四个问题逐一回答：

1. contrib/fulltextindex模块在PostgreSQL 8.1版本被移除的原因 #

这个模块从始至终都是contrib目录下的实验性组件，从未进入核心稳定功能支持列表，被移除的核心原因有三点：

• 功能被更成熟的替代方案完全覆盖：8.1版本同期，tsearch2扩展已经成为社区公认的全文检索方案，也就是后来PostgreSQL内置全文检索功能的前身，支持自定义词典、词干提取、相关性排名等老模块完全没有的能力
• 老模块本身存在不可修复的设计缺陷：不支持索引增量更新，单条文本变动就需要重写对应索引块，写入性能极差；索引膨胀率普遍超过300%；锁粒度为表级，索引构建和更新时会阻塞全表写入，完全无法支撑生产环境使用
• 8.1版本做了contrib目录清理，所有无维护者、有成熟替代的实验性模块都被移出官方源码包，fulltextindex就在清理列表中，之后也没有任何社区维护者接手更新。

2. contrib/fulltextindex模块的使用方式 #

强烈不建议在任何生产、测试甚至个人开发环境使用这个模块，它已经停止维护近20年，存在大量未修复的崩溃、数据损坏bug，也不兼容近20年PostgreSQL的内部API。
如果仅做技术考古研究，你只能获取PostgreSQL 8.0及更早版本的官方源码包，从contrib/fulltextindex目录下拿到原始源码，手动适配后续版本的PostgreSQL内部API后自行编译安装，官方从未提供过高版本的适配包，也没有完整的公开使用文档留存。

3. 支持标准全文索引的数据库解决方案 #

目前主流的支持标准倒排结构全文索引的方案可以分为两类：

• 关系型数据库内置/扩展实现
  • PostgreSQL：原生tsvector+GIN/GIST索引方案，支持自定义分词、词典、短语搜索、结果排名，也可以通过扩展对接外部检索引擎实现更复杂的全文能力
  • MySQL 8.0+：InnoDB引擎内置全文索引，支持多语言分词、布尔检索、相关性排序
  • Microsoft SQL Server：内置全文与语义搜索功能，与查询优化器深度集成，支持非结构化文档内容解析
  • Oracle：Oracle Text组件，支持结构化数据与非结构化文本的混合检索，内置文本分类、摘要提取能力
• 专用全文检索/支持全文索引的分析型数据库
  • Elasticsearch/OpenSearch：基于Lucene构建的分布式检索引擎，是目前全文检索场景的主流方案，支持高亮、向量混合检索、多维度聚合
  • Manticore Search：C++实现的高性能检索引擎，资源占用远低于Elasticsearch，原生支持SQL接口
  • ClickHouse：内置倒排索引，适配海量日志、文本类数据的高速全文检索，分析性能极强
  • Typesense：轻量级开箱即用的检索引擎，低延迟，适合中小规模场景快速落地

4. 标准全文索引方案的常规性能水平 #

性能表现和硬件配置、数据量级、查询复杂度强相关，行业通用场景下的参考值如下：

• 索引构建速度：机械硬盘上单线程索引速度约为10-50MB文本/秒，SSD上单线程可达50-200MB文本/秒；分布式集群可以随节点数线性提升构建速度，10节点规模集群每秒可处理GB级文本写入
• 查询延迟：百万级文档规模下，普通关键词检索延迟稳定在10-100毫秒；亿级文档规模下，命中缓存的热门查询延迟可控制在100毫秒内，冷数据复杂查询（带短语匹配、多条件过滤）延迟通常在1秒以内；如果是带聚合、高亮的复杂查询，延迟会比纯关键词查询高30%-70%
• 存储开销：仅存储词项的基础倒排索引，存储大小约为原始文本的20%-60%；如果额外存储词位置、偏移量（用于短语匹配、结果高亮），存储开销会上升到原始文本的70%-150%

内容的提问来源于stack exchange，提问作者Yorai Levi