POSTGRESQL如何解决LIKE %%的问题

小编给大家分享一下POSTGRESQL如何解决LIKE %%的问题，希望大家阅读完这篇文章之后都有所收获，下面让我们一起去探讨吧！

题目比Big mouth, 在POSTGRESQL 进入视野前，如果我们看到有程序员这样写

Select name from employees where name like '%Chars%';

并且这个表的行数在几百万行到千万行的水平，我们只能给写这个语句的人一句。

Are you lost your mind , 换句话就是 你是疯了吗?

世界不同了，队伍不好带，以前 ORACLE , SQL SERVER , MYSQL 都统一口径说，我们不支持这样 SB 的查询方式，你要不就 写成

select name from emplyees where name like '%Chars'

要不就

select name from employees where name like 'Chars%'

如果非要如此，%% 的like查询，你不如去做全文索引。 就此就将这样的需求已 SB 的标签贴了几十年。 就连ORACLE 这样已经神话的数据库，也对此毫无作为。

"更多选择，更多欢乐"， 当然这欢乐不是给 ORALCE ,SQL SERVER ,MYSQL 这几个家伙的。因为到此为止，这几位，还是只能 TABLE SCAN 对待 like %% 这样的查询，而走不了索引。

POSTGRESQL ，面对几十年解决不了的问题，轻声的说了句，我试试吧

来我们看看POSTGRESQL 怎么能将别的数据库都做不到的事情，轻描淡写的就做完了。

首先我们先做一个实验，先建立一个表，

然后我们插入100的数据

我们看看我们插入了什么样的数据，以NAME 为字段的一堆无序的字符。

为了比较POSTGRESQL 在处理 LIKE %% 这样的数据和全表扫描的区别，我们也建立一个不使用POSTGRESQL 索引的数据表，来做一个对比

名字里面有一个 2

通过POSTGRESQL 独有的GIN 索引，（这只是其中一种解决 LIKE %%方法，还有几种方法还可以面对更大无序的数据去做 like %%）,至于更刺激的事情，还是找个机会下次说。

CREATE INDEX idx_employees_name_gin ON employees USING gin (name gin_trgm_ops);

索引建立完了，我们也需要开始做比较了

结果很明显，employees 1 在使用了 gin 索引后，查询的时间耗时 1.221ms ,而如果不使用索引的情况下 我们要使用 68.484 ms 的时间。

有人可能有异议，说你的比较光是在POSTGRESQL 本身上做的，这不公平，你应该在MYSQL , SQL SERVER , ORACLE 最新版上都做一遍。

我只想说，当我看到100万的数据，在用LIKE %% 查询还能走索引，在一个破笔记本上的时间是 1.221ms，我已经毫无愿望在去测那些数据库了，毫无意愿， 而更可笑的是， 这样一个数据库他是免费的，比MYSQL 免费的还彻底。 面对 SQL SERVER ORACLE 收取巨额费用，几十年了还解决不了这样like %% 的问题。

看完了这篇文章，相信你对"POSTGRESQL如何解决LIKE %%的问题"有了一定的了解，如果想了解更多相关知识，欢迎关注行业资讯频道，感谢各位的阅读！