PostgreSQL中CAST为character(1)与LIKE语句的性能对比：mycolumn::character(1)='4'与mycolumn LIKE '4%'哪个更快？

嘿，这个问题问得相当务实！我来帮你拆解PostgreSQL里这两种查询写法的性能差异，分场景说清楚：

核心逻辑先理清 #

先看看这两个语句到底在做什么：

• mycolumn::character(1)='4'：先把每条记录的mycolumn值强制转换为长度1的字符类型，再和'4'比较。这个类型转换是逐行执行的额外操作。
• mycolumn LIKE '4%'：直接在原字段值上做前缀匹配，找所有以'4'开头的记录，没有额外的转换步骤。

分场景看性能差异 #

1. 没有任何索引的全表扫描场景 #

两种写法都得遍历整张表，但mycolumn::character(1)='4'多了一层类型转换的开销——哪怕这个转换很轻量，累积到百万级以上的记录时，差距就会显现出来。LIKE '4%'因为直接做前缀匹配，会略快一些。

2. 有合适索引的场景（性能差距最大的情况） #

这才是关键：

• 对于mycolumn LIKE '4%'：如果mycolumn上有普通的B-tree索引（比如CREATE INDEX idx_my_table_mycolumn ON my_table(mycolumn);），PostgreSQL可以直接利用索引做前缀扫描，快速定位到所有符合条件的记录，完全不需要全表扫描，性能拉满。
• 对于mycolumn::character(1)='4'：普通的B-tree索引根本用不上，因为索引是基于原字段值构建的，而查询时我们对字段做了转换。除非你专门创建函数索引：CREATE INDEX idx_my_table_mycolumn_char1 ON my_table((mycolumn::character(1)));，否则这条语句还是会走全表扫描，性能远不如带索引的LIKE '4%'。

3. 数据类型的影响（text vs character(200)） #

其实这两种字段类型对这两个查询的性能影响微乎其微：

• character(200)是固定长度类型，存储时会用空格填充到200位，但PostgreSQL查询时会自动忽略末尾空格，所以LIKE '4%'在它上面的表现和text几乎一致。
• 类型转换::character(1)在两种类型上的开销也没区别，都是取第一个字符做转换。

总结建议 #

• 优先用mycolumn LIKE '4%'：不管有没有索引，它的表现都不会比另一种写法差，有索引时更是性能碾压。
• 只有当你已经为mycolumn::character(1)创建了专门的函数索引时，两种写法的性能才会接近，但这种场景其实很少见。

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