Postgresql SELECT 性能和优化答案

【问题标题】：Postgresql SELECT performance and optimizationPostgresql SELECT 性能和优化
【发布时间】：2021-07-29 11:38:07
【问题描述】：

我有一个有 14_000 行的表。不是很多。我的查询

SELECT "wells".* FROM "wells" WHERE (LOWER(name) LIKE '%abc%' OR code LIKE '%ABC%')
  ORDER BY "wells"."name_nso" ASC, "wells"."extra_name" ASC
  LIMIT 10;

需要“执行时间：2.701 毫秒”

对于这个表，我有两个索引：

CREATE INDEX wells_btree_idx_on_name_nso
ON public.wells USING btree
(name_nso COLLATE pg_catalog."default" ASC NULLS LAST)
TABLESPACE pg_default;

和

CREATE INDEX wells_gin_idx_on_name_lower
ON public.wells USING gin
(lower(name) COLLATE pg_catalog."default" gin_trgm_ops)
TABLESPACE pg_default;

如果我删除 LIMIT 10，则需要“执行时间：0.894 毫秒”。快 4 倍。

是否值得研究如何将 LIMIT 10 的查询加速到 0.894 毫秒，或者这 2.701 毫秒是否足够快且不值得费心？

【问题讨论】：

进行模糊字符串匹配总是比精确匹配慢。您可以做很多事情 - 例如。如果您有预定义的组，您可以使用它们构建物化视图并查询精确匹配。归根结底，答案是 - 它总是取决于。您是否运行一次查询？还是几千次？如果它很少运行，您可以等待。如果不是 -> 你最好提高你的数据库技能：D
只有你可以决定 2.7ms 是否“足够快”。
查询很少执行。但是，如果某些事情可以更快地执行，为什么不让它更快呢。谢谢
这是我们测量极短时间间隔的能力以及完全无法用人类术语插入该时间的另一个例子吗？有人会注意到这个过程需要 0.0027 秒与 0.00089 秒吗？是的，第 1 次要长 3 到 4 倍，但即使如此也超出了我们的认知。
嗨@sssebaaa 文本搜索总是很慢而不是整数。在存在代码列的位置创建另一个索引或创建复合索引。默认情况下 order by 子句按升序工作，因此无需按 order by 子句键入 ASC。

标签： postgresql query-optimization

【解决方案1】：

在使用不区分大小写排序规则运行 LIKE 运算符时，PostGreSQL 是最慢的 RDBMS。您需要使用 LOWER 或 UPPER，因为 ICU 排序规则存在错误... 读： https://www.postgresql.org/message-id/CACykOPQKHGRLzuAB1Mvn9Pizatp9g%3DJG_CHYxn4VOD%2BD7E4Vcg%40mail.gmail.com

您可以使用 citext 类型来执行此操作...

你的索引不会有用，用两个 % 倒 LIKE...

【讨论】：