相关疑难解决方法(0)

假设我有一个包含字段A和的表B。我在A+上进行常规查询B，所以我在 上创建了一个复合索引(A,B)。A复合索引是否也会对查询进行全面优化？

此外，我在 上创建了一个索引A，但 Postgres 仍然只使用复合索引来查询A。如果前面的答案是肯定的，我想这并不重要，但是为什么它默认选择复合索引，如果单个A索引可用？

此查询获取您关注的人创建的帖子列表。您可以关注无限数量的人，但大多数人关注 < 1000 人。

使用这种查询方式，明显的优化是缓存"Post"id，但不幸的是我现在没有时间这样做。

EXPLAIN ANALYZE SELECT
    "Post"."id",
    "Post"."actionId",
    "Post"."commentCount",
    ...
FROM
    "Posts" AS "Post"
INNER JOIN "Users" AS "user" ON "Post"."userId" = "user"."id"
LEFT OUTER JOIN "ActivityLogs" AS "activityLog" ON "Post"."activityLogId" = "activityLog"."id"
LEFT OUTER JOIN "WeightLogs" AS "weightLog" ON "Post"."weightLogId" = "weightLog"."id"
LEFT OUTER JOIN "Workouts" AS "workout" ON "Post"."workoutId" = "workout"."id"
LEFT OUTER JOIN "WorkoutLogs" AS "workoutLog" ON "Post"."workoutLogId" = "workoutLog"."id"
LEFT OUTER JOIN "Workouts" AS "workoutLog.workout" ON "workoutLog"."workoutId" = "workoutLog.workout"."id"
WHERE
"Post"."userId" IN …

问这个问题，特别是针对 Postgres，因为它对 R 树/空间索引有很好的支持。

我们有下表，其中包含单词及其频率的树结构（嵌套集模型）：

lexikon
-------
_id   integer  PRIMARY KEY
word  text
frequency integer
lset  integer  UNIQUE KEY
rset  integer  UNIQUE KEY

和查询：

SELECT word
FROM lexikon
WHERE lset BETWEEN @Low AND @High
ORDER BY frequency DESC
LIMIT @N

我认为覆盖索引(lset, frequency, word)会很有用，但我觉得如果范围内的lset值太多，它可能表现不佳(@High, @Low)。

(frequency DESC)有时，当使用该索引的搜索早期产生@N与范围条件匹配的行时，一个简单的索引也可能就足够了。

但似乎性能在很大程度上取决于参数值。

有没有办法让它快速执行，不管范围(@Low, @High)是宽还是窄，也不管高频词是否幸运地在（窄）选择的范围内？

R-tree/空间索引有帮助吗？

添加索引，重写查询，重新设计表，没有限制。

使用PostgreSQL 10.5。我正在尝试创建一个分页系统，用户可以在其中来回切换各种结果。

为了不使用OFFSET，我id在名为p(prevId)的参数中从上一页的最后一行传递了。然后我选择id高于p参数中传递的数字的前三行。（如本文所述）

例如，如果id上一页的最后一行是 5，我会选择前 3 行的 anid大于 5：

SELECT 
  id, 
  firstname, 
  lastname 
FROM 
  people 
WHERE 
  firstname = 'John'
  AND id > 5 
ORDER BY 
  ID ASC 
LIMIT 
  3;

这很好用，而且时机也不错：

Limit  (cost=0.00..3.37 rows=3 width=17) (actual time=0.046..0.117 rows=3 loops=1)
   ->  Seq Scan on people  (cost=0.00..4494.15 rows=4000 width=17) (actual time=0.044..0.114 rows=3 loops=1)
         Filter: ((id > 5) AND (firstname = 'John'::text))
         Rows Removed by Filter: …

简介： 我有一个简单的数据库模式，但即使只有几十条记录，基本查询的性能也已经成为一个问题。

数据库：PostgreSQL 9.6

简化架构：

CREATE TABLE article (
  id bigint PRIMARY KEY,
  title text NOT NULL,
  score int NOT NULL
);
CREATE TABLE tag (
  id bigint PRIMARY KEY,
  name text NOT NULL
);
CREATE TABLE article_tag (
  article_id bigint NOT NULL REFERENCES article (id),
  tag_id bigint NOT NULL REFERENCES tag (id),
  PRIMARY KEY (article_id, tag_id)
);
CREATE INDEX ON article (score);

生产数据信息：

所有表都是读/写的。写入量低，每几分钟左右只有一个新记录。

大概记录数：

• ~66K 篇文章
• ~63K 标签
• ~147K article_tags

每篇文章平均 5 个标签。

问题 …

我有一个带有遗留查询的 Rails 应用程序，我想对其进行翻新。当前实现执行两个 SQL 查询：一个获取大量 ID，第二个查询使用这些 ID 并应用一些额外的连接和过滤器来获得所需的结果。

我试图用避免往返的单个查询替换它，但这样做会导致我的本地测试环境（这是完整生产数据集的副本）的性能大幅下降。新查询中似乎没有使用索引，导致全表扫描。我曾希望单个查询能够保持与原始代码相同的性能，理想情况下，由于不需要发送所有 ID，因此可以对其进行改进。

这是我实际问题的最小化版本。稍大一点的版本在讨论为什么10000个ID的列表中一个复杂的查询有更好的表现与多个热膨胀系数相比，相当于SQL选择它们？.

当前查询

有一个查询需要大约 6.5 秒来计算 10000 多个 ID 的列表。您可以visible_projects在下面的“建议查询”部分中将其视为 CTE 。然后将这些 ID 输入到此查询中：

EXPLAIN (ANALYZE, BUFFERS)
WITH visible_projects AS NOT MATERIALIZED (
    SELECT
        id
    FROM
        "projects"
    WHERE
        "projects"."id" IN (
            -- 10000+ IDs removed
)),
visible_tasks AS MATERIALIZED (
    SELECT
        tasks.id
    FROM
        tasks
    WHERE
        tasks.project_id IN (
            SELECT
                id
            FROM
                visible_projects))
SELECT
    COUNT(1)
FROM
    visible_tasks;

查询计划（depesz）

Aggregate  (cost=1309912.31..1309912.32 rows=1 width=8) (actual time=148.661..153.739 …

我有一个中等大小的“functionCalls”表（约 4M 行），由 2 列组成，input并且function（另一个表的两个 id）：

  Column  |  Type   | Collation | Nullable | Default \n----------+---------+-----------+----------+---------\n input    | integer |           | not null | \n function | integer |           | not null | \nIndexes:\n    "functionCall_pkey" PRIMARY KEY, btree (input, function) CLUSTER\n    "functionCallSearch" btree (function, input)\nForeign-key constraints:\n    "fkey1" FOREIGN KEY (function) REFERENCES function(id) ON UPDATE CASCADE ON DELETE CASCADE\n    "fkey2" FOREIGN KEY (input) REFERENCES input(id)\n\n

我想找到与某个函数匹配的所有行，这就是我添加索引的原因functionCallSearch。这是我的查询：

  Column  |  Type   | Collation | …