Postgresql 从那个点看要优于 ORACLE SQL SERVER MYSQL

很早的一篇文字, 今天遇到了问题,开发问我怎么解决, 又翻出来, PG 的优越性比 ORACLE SQL SERVER MYSQL 高明的地方,就体现在下方的文字

正文：

本来上次是写过这个PostgreSQL 的功能的，但上次在一个论坛里面发现其实大家对这个功能认识上是有误区的，所示这次是的详细的一次文字。

功能很简单的就是模糊查询，类似 select * from table where column1 like ‘%PG牛逼%’；然后走一个靠谱的索引的查询，ORACLE 打死他都不行，当然可以走全文索引，那MYSQL, SQL SERVER 人家也不干，人家也有这功能。

pg_trgm本身是不包含在PostgreSQL 的源码安装中的，当然是插件的方式安装，安装上是很简单的，具体请百度（弄湿了我可不管）

进入到你的数据库，create extension pg_trgm；就OK 了

我在论坛中发现的第一个问题，是说建立这样的模糊查询，仅仅建立btree 索引就可以了，但pg_trgm 只支持两种索引Gist and Gin, 这两种索引。（这可不是我说的，官方的白纸黑字）

所以说正确的针对一个列的索引，是要建立两个索引的，一个是BTREE 索引，一个是 GIN 或 Gist 索引，两种索引面对的“客户”是不同的。

那我们来看看到底他是怎么工作的

首先我们先生成一个表用来测试

创建一个存储过程用来插入测试数据

create or replace function data_produce(int) returns text as $$    
declare    
  res text;    
begin    
  if $1 >=1 then    
    select string_agg(chr(19968+(random()*20901)::int), '') into res from generate_series(1,$1);    
    return res;    
  end if;    
  return null;    
end;    
$$ language plpgsql strict; 

insert into test_pg_trgm (search) select data_produce(20) from generate_series(1,1110000);

执行后生成我们本次要测试的数据10万条

下面我们创建索引了，创建GIN 索引

创建索引中系统报错，这是由于还没有创建相关的扩展

添加了这些扩展后我们就可以建立相关的索引

我们可以看到查询已经走了索引，并且查询时间1ms

那如果我们没有这个索引会怎么样，这条语句慢了 48倍并且只能和ORACLE SQL SERVER , MYSQL一样走了全表扫描。

OK 如果已经体会到了PG 在模糊查询中的厉害之处，群里有人问的第二个问题是 GIN VS GIST 那种索引更好

这也是一个热门的问题？

下面也做一个测试，（但不证明GIN 比 GIST 性能强），我们建立一个gist的索引，也提通过查询来进行模糊方式的查询

图中的时间 12ms ，比全表扫描快了4倍，比GIN 慢了12倍

当然这里并不是说 GIST 不如GIN ，具体的索引有不同的使用场景。（做人办事都的客观）

最后，我们来证明一下，普通的运算方式对于GIST GIN 索引是无效的，所以我们对某个字段必须建立两个索引 BTREE AND GIST OR GIN。

下图整体的证明了上面的立论。这里就不解释了

最后回归题目，PG 为何“大爱”程序员，想想一个不靠谱的模糊需求能把一个程序员弄得“五脊六瘦”（具体是那个地方的方言请脑补），而PG 可以将这个事情化解，难道还不是程序员的“大爱”。