使用串联和 LIKE 的查询性能

有人可以解释这 3 个查询之间的性能差异吗？

concat()功能：

explain analyze 
select * from person 
where (concat(last_name, ' ', first_name, ' ', middle_name) like '%Ива%');

Seq Scan on person  (cost=0.00..4.86 rows=1 width=15293) (actual time=0.032..0.140 rows=6 loops=1)
  Filter: (pg_catalog.concat(last_name, ' ', first_name, ' ', middle_name) ~~ '%Ива%'::text)
Total runtime: 0.178 ms

SQL 标准连接||:

explain analyze 
select * from person 
where ((last_name || ' ' || first_name || ' ' || middle_name) like '%Ива%');

Seq Scan on person  (cost=0.00..5.28 rows=1 width=15293) (actual time=0.023..0.080 rows=6 loops=1)
  Filter: ((((((last_name)::text || ' '::text) || (first_name)::text) || ' '::text) || (middle_name)::text) ~~ '%Ива%'::text)
Total runtime: 0.121 ms

分别搜索字段：

explain analyze 
select * from person 
where (last_name like '%Ива%') or (first_name like '%Ива%') or (middle_name like '%Ива%');

Seq Scan on person  (cost=0.00..5.00 rows=1 width=15293) (actual time=0.018..0.060 rows=6 loops=1)
  Filter: (((last_name)::text ~~ '%Ива%'::text) OR ((first_name)::text ~~ '%Ива%'::text) OR ((middle_name)::text ~~ '%Ива%'::text))
Total runtime: 0.097 ms

Why is concat()最慢的一个，为什么有几个like条件更快？

虽然不是具体答案，但以下内容可能会帮助您得出一些结论：

1. Calling concat连接三个字符串，或使用||运算符，导致 postgres 必须分配一个新的缓冲区来保存连接的字符串，然后将字符复制到其中。必须对每一行执行此操作。然后缓冲区必须在最后被释放。

2. 如果您将三个条件进行“或”运算，postgres 可能只需评估其中的一个或两个条件即可决定是否必须包含该行。

3. 表达式求值可以使用||与函数调用相比，运算符可能更高效，或者更容易优化concat。如果发现内部操作员有一些特殊情况处理，我不会感到惊讶。

4. 正如评论中提到的，您的样本太小，无论如何都无法得出正确的结论。在几分之一毫秒的水平上，其他噪声因素可能会扭曲结果。