前面几篇我们依次拆解了 OceanBase 4.3 全文检索（FTS）的五种分词解析器：空白分词、N-gram、N-gram2、英文基础分词 beng、IK 中文分词，以及停用词检查器和插件助手。它们各自独立成文件，但有一个共同的”出生地”——今天要讲的 ob_fts_builtin_parser_register.cpp。这个文件只有 76 行，却是整个 FTS 分词体系的总装车间：五种内置分词器在这里统一以”内置插件”的身份注册进插件框架，进程启动时即完成装配，这就是全文索引功能开箱即用的秘密。
继续阅读OceanBase源码解读：FTS内置解析器插件注册 ob_fts_builtin_parser_register
全文索引的质量，很大程度上取决于”哪些词值得进倒排”。用户文档里的 the、is、of 这类高频虚词，以及单个字母、超长乱码，塞进倒排表只会白白膨胀索引、拖慢检索。OceanBase 4.3 的全文检索（FTS）模块专门用一个文件管这件事：storage/fts/ob_fts_stop_word.cpp。它包含两个核心类——ObStopWordChecker（停用词哈希集合，负责判断一个词是否该被丢弃）和 ObAddWord（词项收集器，所有解析器产出的 token 都要过它这道”质检流水线”才能写入倒排）。理解这个文件，就理解了从”分词器吐出一串 token”到”倒排表里一个词项+词频”之间的全部加工逻辑。
在 OceanBase 4.3 的全文检索（FTS）体系里，每一种分词器都由「插件描述符 + 分词执行器」两个角色配合完成。本文要看的 ob_beng_ft_parser.cpp 实现的是内置的英文基础分词解析器（parser_type = beng），全部代码只有 195 行，却是理解 FTS 插件框架最干净的样本：它把 ObEnglishAnalyzer（SQL 层的英文分词器）包装成全文索引可用的词项迭代器，完整展示了分词请求从创建到销毁的生命周期管理。与 ngram、ik、whitespace 等解析器一样，它通过 ob_fts_builtin_parser_register 注册为内置解析器，供建 FULLTEXT INDEX（WITH PARSER beng）与全文查询时调用。
在 OceanBase 4.3 的全文检索（FTS）插件族里，ob_ngram2_ft_parser.cpp 是一个”轻包装层”：真正的滑动窗口切词逻辑在 ObFTNgramImpl 中实现，本文件只负责把 impl 包装成符合插件接口的迭代器。与固定窗口的 ob_ngram_ft_parser 相比，它的最大差异是支持 [min_ngram_size_, max_ngram_size_] 区间窗口——既可以退化为固定 N-gram（min==max），也可以做变长 N-gram 切分。
在 OceanBase 4.3 的全文检索（FTS）体系里，分词器是以插件形式挂载的，前面几篇我们已经看过空白分词器和 IK 中文分词器。这篇要解读的是家族里最”简单粗暴”的一位——N-gram 分词器（源码：storage/fts/ob_ngram_ft_parser.cpp，全文仅 156 行）。它的切词哲学是不依赖任何词典、不做任何语言理解，直接把文本按 N 个字符的滑动窗口硬切：比如 “数据库” 以 ngram_token_size=2 切出来就是 “数据”、”据库” 两个词项。好处是天然支持任意语言、绝对零漏召回（任何查询串都能命中）；代价是词项数量暴涨、索引体积膨胀，而且词项没有语义边界。全文检索在建索引和查询两侧都调用同一个分词器，所以两侧的一致性由插件机制天然保证。
本文解析 OceanBase 4.3 全文检索（FTS）模块中的内置默认分词器——空白分词解析器（space parser）。它位于 storage/fts/ 目录，以 PARSER_NAME_SPACE("space") 注册到系统，是全文索引建立与查询时最轻量的词元切分方案。与 ngram（固定长度滑动窗口）、ik（中文 IK 分词，需词典）、beng（基础英文分析器）相比，space parser 无需词典、无需滑动窗口，仅依据「词字符/非词字符」边界切分，适合以英文、数字为主的语料场景。
在 OceanBase 4.3 的全文检索体系里，用户建全文索引时可以顺便”调教”分词器——比如指定 IK 模式、自定义词典表、控制 token 长度上下限。这些配置以 JSON 形式跟着 WITH PARSER 一起写进 DDL，而负责接住它们的就是本文的主角：src/storage/fts/ob_fts_parser_property.cpp。这个文件有两个核心类：ObFTParserJsonProps 用一棵 JSON 树作为属性的统一内存表示，负责解析、校验、落库和 DDL 回显；ObFTParserProperty 则是面向分词执行期的”扁平视图”，把 JSON 属性摊平成几个标量字段，供 ObFTParseHelper 等运行时组件直接取用。一个管”存”，一个管”用”，分工清晰。
全文检索（FTS）在 OceanBase 4.3 里被拆成了多层：底层有 space/ngram/beng/ik/ngram2 等具体分词器，中间有停用词、词典缓存，上层索引构建只需要一个统一 facade。本文解读的 storage/fts/ob_fts_plugin_helper.cpp 就是这个 facade 与资源管理层：它负责 parser 名字解析、进程级全局数据初始化、单次分词请求的参数装配，以及把分词结果输出成 JSON 倒排文档。全文检索链路中的分词动作，最终都会收敛到这个文件里的 ObFTParseHelper::segment。
OceanBase 4.3.5 引入了「堆表（HEAP ORGANIZED TABLE）」，这是这套存储引擎第一次把「索引组织表」作为默认范式之外，又给出了一种可选的行存布局。很多人第一反应是「不就是没有主键索引的普通表吗」，但翻一遍源码会发现它改的东西远比「建不建索引」更深：用户主键被降级成了一棵独立的唯一索引，主表的 rowkey 换成了一个隐藏的自增列。这篇文章从源码层面把这件事讲清楚，并对照说明它对查询、写入和功能支持上的全部影响。
在 OceanBase 4.3 的全文检索（Full-Text Search, FTS）体系中，倒排索引的构建与查询都需要一种能力：按文档维度读取”词项明细”——即某篇文档包含了哪些词、每个词出现了多少次、出现在什么位置。本文解读的 ObFTDocWordScanIterator 正是承担这一职责的核心组件，它位于 storage/fts/ 目录，衔接上层的 FT 索引构建流程与底层的通用存储扫描接口。