postgresql 低LIKE vs iLIKE

8ljdwjyq  于 2023-08-04  发布在  PostgreSQL
关注(0)|答案(3)|浏览(215)

下面两个查询组件的性能比较如何?

低喜欢

... LOWER(description) LIKE '%abcde%' ...

字符串

iLIKE

... description iLIKE '%abcde%' ...

bkkx9g8r

bkkx9g8r1#

答案取决于许多因素,如Postgres版本,编码和区域设置-特别是LC_COLLATE
裸表达式lower(description) LIKE '%abc%'通常比description ILIKE '%abc%'快一点,也比等价的正则表达式快一点:description ~* 'abc'。这对于顺序扫描很重要,在顺序扫描中,必须为每个测试行计算表达式。

但是对于像你在答案中演示的大表,肯定会使用索引。对于任意模式(不仅是左锚模式),我建议使用附加模块pg_trgm的三元组索引。然后我们讨论毫秒而不是秒,上面表达式之间的差异就无效了。

GIN和GiST索引(使用gin_trgm_opsgist_trgm_ops操作符类)支持LIKE~~),ILIKE~~*),~~*(以及更多变体)。使用description上的三元GIN索引(通常大于GiST,但读取速度更快),您的查询将使用description ILIKE 'case_insensitive_pattern'
相关信息:

  • PostgreSQL LIKE查询性能变化
  • 自动完成字段的类似UTF-8字符串

Postgres中模式匹配的基础知识:

当使用上述三元组索引时,它 * 通常 * 更实用:

description ILIKE '%abc%'

字符串
或者使用不区分大小写的regexp运算符(不带%通配符):

description ~* 'abc'


(description)上的索引不支持lower(description)上的查询,如:

lower(description) LIKE '%abc%'


反之亦然。
对于lower(description)上的 predicate exclusively,表达式索引是稍微好一点的选择。
在所有其他情况下,(description)上的索引更可取,因为它支持 both 大小写敏感和不敏感 predicate 。

wgeznvg7

wgeznvg72#

根据我的测试(每个查询 * 10 *),LOWERLIKEiLIKE快大约17%

说明

我创建了一百万行包含一些随机混合文本数据:

require 'securerandom'
inserts = []
1000000.times do |i|
        inserts << "(1, 'fake', '#{SecureRandom.urlsafe_base64(64)}')"
end
sql = "insert into books (user_id, title, description) values #{inserts.join(', ')}"
ActiveRecord::Base.connection.execute(sql)

字符串
验证行数:

my_test_db=# select count(id) from books ;
  count  
---------
 1000009


(Yes,我从其他测试中多出了九行-不是问题。)
示例查询和结果:

my_test_db=# SELECT "books".* FROM "books" WHERE "books"."published" = 'f'
my_test_db=# and (LOWER(description) LIKE '%abcde%') ;
   id    | user_id | title |                                      description                                       | published 
---------+---------+-------+----------------------------------------------------------------------------------------+------
 1232322 |       1 | fake  | 5WRGr7oCKABcdehqPKsUqV8ji61rsNGS1TX6pW5LJKrspOI_ttLNbaSyRz1BwTGQxp3OaxW7Xl6fzVpCu9y3fA | f
 1487103 |       1 | fake  | J6q0VkZ8-UlxIMZ_MFU_wsz_8MP3ZBQvkUo8-2INiDIp7yCZYoXqRyp1Lg7JyOwfsIVdpPIKNt1uLeaBCdelPQ | f
 1817819 |       1 | fake  | YubxlSkJOvmQo1hkk5pA1q2mMK6T7cOdcU3ADUKZO8s3otEAbCdEcmm72IOxiBdaXSrw20Nq2Lb383lq230wYg | f

Lower Like的结果

my_test_db=# EXPLAIN ANALYZE SELECT "books".* FROM "books" WHERE "books"."published" = 'f' and (LOWER(description) LIKE '%abcde%') ;
                                                   QUERY PLAN                                                   
----------------------------------------------------------------------------------------------------------------
 Seq Scan on books  (cost=0.00..32420.14 rows=1600 width=117) (actual time=938.627..4114.038 rows=3 loops=1)
   Filter: ((NOT published) AND (lower(description) ~~ '%abcde%'::text))
   Rows Removed by Filter: 1000006
 Total runtime: 4114.098 ms

iLIKE搜索结果

my_test_db=# EXPLAIN ANALYZE SELECT "books".* FROM "books" WHERE "books"."published" = 'f' and (description iLIKE '%abcde%') ;
                                                   QUERY PLAN                                                   
----------------------------------------------------------------------------------------------------------------
 Seq Scan on books  (cost=0.00..29920.11 rows=100 width=117) (actual time=1147.612..4986.771 rows=3 loops=1)
   Filter: ((NOT published) AND (description ~~* '%abcde%'::text))
   Rows Removed by Filter: 1000006
 Total runtime: 4986.831 ms

数据库信息泄露

Postgres版本:

my_test_db=# select version();
                                                                                 version
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 PostgreSQL 9.2.4 on x86_64-apple-darwin12.4.0, compiled by i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00), 64-bit


排序规则设置:

my_test_db=# select datcollate from pg_database where datname = 'my_test_db';
 datcollate  
-------------
 en_CA.UTF-8


表格定义:

my_test_db=# \d books 
                                      Table "public.books"
   Column    |            Type             |                       Modifiers
-------------+-----------------------------+-------------------------------------------------------
 id          | integer                     | not null default nextval('books_id_seq'::regclass)
 user_id     | integer                     | not null
 title       | character varying(255)      | not null
 description | text                        | not null default ''::text
 published   | boolean                     | not null default false
Indexes:
    "books_pkey" PRIMARY KEY, btree (id)

huus2vyu

huus2vyu3#

在我的Rails项目中。ILIKE几乎比LOWER LIKE快10倍,我在entities.name列上添加了GIN索引

> Entity.where("LOWER(name) LIKE ?", name.strip.downcase).limit(1).first
Entity Load (2443.9ms)  SELECT  "entities".* FROM "entities" WHERE (lower(name) like 'baidu') ORDER BY "entities"."id" ASC LIMIT $1  [["LIMIT", 1]]
> Entity.where("name ILIKE ?", name.strip).limit(1).first
Entity Load (285.0ms)  SELECT  "entities".* FROM "entities" WHERE (name ilike 'Baidu') ORDER BY "entities"."id" ASC LIMIT $1  [["LIMIT", 1]]
# explain analyze SELECT  "entities".* FROM "entities" WHERE (name ilike 'Baidu') ORDER BY "entities"."id" ASC LIMIT 1;
                                                                   QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=3186.03..3186.04 rows=1 width=1588) (actual time=7.812..7.812 rows=1 loops=1)
   ->  Sort  (cost=3186.03..3187.07 rows=414 width=1588) (actual time=7.811..7.811 rows=1 loops=1)
         Sort Key: id
         Sort Method: quicksort  Memory: 26kB
         ->  Bitmap Heap Scan on entities  (cost=1543.21..3183.96 rows=414 width=1588) (actual time=7.797..7.805 rows=1 loops=1)
               Recheck Cond: ((name)::text ~~* 'Baidu'::text)
               Rows Removed by Index Recheck: 6
               Heap Blocks: exact=7
               ->  Bitmap Index Scan on index_entities_on_name  (cost=0.00..1543.11 rows=414 width=0) (actual time=7.787..7.787 rows=7 loops=1)
                     Index Cond: ((name)::text ~~* 'Baidu'::text)
 Planning Time: 6.375 ms
 Execution Time: 7.874 ms
(12 rows)

GIN索引确实有助于提高ILIKE的性能

相关问题