OceanBase 全文索引与列存索引的对比与选型分析
在现代企业的数据系统中，面对日益增长的文档内容、富文本信息与分析型查询需求，索引机制的选型直接决定了数据库的查询效率与系统性能。OceanBase 作为一款分布式关系型数据库，提供了两种针对不同场景的索引能力：全文索引（FullText Index） 与 列存索引（Columnar Index） 。二者虽然都属于索引体系，但在底层设计逻辑、支持的数据类型、性能优化方向以及使用限制上差异明显，合理选型至关重要。
全文索引 主要面向文本检索场景。它通过分词、倒排索引等技术，将文本文档分解为词条，从而实现快速的关键词匹配与模糊搜索。在 OceanBase 的 MySQL 模式中，用户可以通过如下语法创建全文索引：
CREATE FULLTEXT INDEX ft_richtext
ON doc_table(name, richtext)
WITH PARSER ngram
PARSER_PROPERTIES=(ngram_token_size=1);
该语法基于 ngram 分词器，支持中英文混合文本的分词与检索，适用于搜索“项目”、“报告”、“客户名称”等富文本内容。对于存储大量 VARCHAR 或 TEXT 字段的业务表（如知识库、问卷系统、文档管理等），全文索引可显著提高文本检索性能。然而，它的适用范围也相对有限：仅能用于字符型字段，不支持 JSON、BLOB 等复杂类型，且不适合高频写入的表。全文索引在创建和更新过程中会产生较高的 CPU 和存储开销，因此更适用于以查询为主、写入频率较低的场景。
相比之下，列存索引（Columnar Index）则是 OceanBase 针对分析型负载（OLAP）推出的性能增强特性。其核心思想是按列组织和压缩数据，使得系统在执行聚合（SUM、AVG）、过滤和分组操作时能够只读取相关列，显著降低 I/O 与内存消耗。列存索引的典型创建语句如下：
create index idx_name on doc_table(`name`) with column group(each column);
当执行诸如统计点赞数、按层级汇总等 BI 报表查询时，优化器可以自动选择列存索引，大幅提升聚合查询的性能。列存索引在 OceanBase 4.2 及以上版本中得到支持，但它同样存在约束：不支持 TEXT、JSON、BINARY 类型；不宜用于高频更新或事务密集型表；且创建和维护列存索引会占用额外的存储空间。因此，它更适合用于对现有行存表的分析型扩展，而非主数据表的实时检索。
综合来看，全文索引与列存索引分别面向不同的查询维度：前者解决“文字内容检索”的问题，后者解决“数值型分析聚合”的问题。对于类似 doc_table 这样的文档类业务表，如果系统核心需求是对 name、richtext 等富文本进行模糊搜索，优先选择 全文索引；而若业务重点在于对文档层级、点赞统计等结构化字段进行汇总分析，则应启用 列存索引 或单独建立列存副本表。两者并非互斥，而是可以在一个 HTAP（混合事务与分析处理）架构中协同使用。
总体而言，OceanBase 的全文索引侧重检索能力，而列存索引侧重计算性能。前者像“图书馆的目录系统”，帮助你快速定位含有特定关键词的文本；后者更像“数据仓库的列式压缩”，让系统在大规模数据统计时轻装上阵。在选型时，应根据数据类型、访问模式与性能目标进行权衡，以实现存储与查询的最优平衡。
