PostgreSQL中split_part替代like查询的可行性及大数据量选型建议

在吉字节级生产场景下，带前缀锚定的like查询方案整体远优于split_part函数拆分方案，200行小数据量下测出的规划时间差异不具备生产环境选型参考价值。

规划时间的实际影响 #

测出的like查询120ms的规划时间差异，是首次执行未缓存规划结果下的特殊现象：

• PostgreSQL查询规划器碰到带通配符的like语句时，需要额外校验列统计信息、估算匹配行数、判断可命中的索引类型，这部分开销是单次会话内的一次性成本。只要将固定查询模板做成预编译语句，规划结果会被会话缓存，不会在后续重复执行时反复计算。
• 当表容量达到吉字节级，单条查询的执行时间通常在几百毫秒到数秒区间，首次几十毫秒级的规划时间差异占总耗时的比例不足5%，完全不会成为性能瓶颈。
• 小数据量下规划时间占比过高的现象，本质是200行的全表执行耗时本身只有2~3ms，放大了规划环节的微小波动，不代表大表下的真实表现。

执行效率的真实差异 #

两个方案在大表下的性能差距是数量级级别的：

• 对name like 'Vinod.Game%'这类从字符串开头锚定匹配的查询：
  只要name列的排序规则为C/POSIX，即可通过普通B树索引直接命中索引扫描，不需要扫描全表；即便使用默认排序规则，也可以通过pg_trgm扩展建GIN索引加速这类前缀匹配的like查询，匹配过程是直接比对字符串前缀，CPU开销极低。
• 对split_part(name, '.Game', 1) = 'Vinod'这类查询：
  表达式套在列上的写法会直接阻断普通索引的命中，只要没有专门为这个split_part表达式建专属的函数索引，数据库必须对全表每一行的name字段做一次字符串拆分、值比对的计算操作，属于强制全表扫描。哪怕专门建了对应的函数索引，后续如果存储格式调整（比如分隔符从.Game改为_Game），整套索引和查询逻辑都需要同步修改，长期维护成本极高。
  200行测试中观察到的split_part执行时间略高于like的现象，本质是字符串拆分计算的CPU开销比直接前缀比对更高，这个趋势在大表全表扫描的场景下会被放大几个数量级。
  同时这类写法存在逻辑边界漏洞：如果存在类似X.Vinod.Game1的异常存储值，split_part拆分返回的是X而非预期的Vinod，和“查询开头为Vinod.Game”的原始需求存在偏差。

当前表结构里的所有字段都使用varchar类型，没有拆解结构化的业务标识，长期来看更合理的优化方向是把用户标识、游戏标识从name字段里拆成独立列，配合普通索引加速查询，从根本上避免字符串解析带来的额外开销。

内容的提问来源于stack exchange，提问作者Vinod Kumar Chaganti