相关疑难解决方法(0)

我有一个 PostgreSQL 表。select *很慢，但又select id好又快。我认为可能是行的大小非常大并且需要一段时间来运输，或者可能是其他一些因素。

我需要所有字段（或几乎所有字段），因此仅选择一个子集不是一个快速解决方案。选择我想要的字段仍然很慢。

这是我的表架构减去名称：

integer                  | not null default nextval('core_page_id_seq'::regclass)
character varying(255)   | not null
character varying(64)    | not null
text                     | default '{}'::text
character varying(255)   | 
integer                  | not null default 0
text                     | default '{}'::text
text                     | 
timestamp with time zone | 
integer                  | 
timestamp with time zone | 
integer                  | 

文本字段的大小可以是任意大小。但是，在最坏的情况下，不会超过几千字节。

问题

1. 有什么关于这叫“疯狂低效”的吗？
2. 有没有办法在 Postgres 命令行中测量页面大小来帮助我调试？

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

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

我有几个关于在 PostgreSQL 中使用索引的问题。我有一个Friends带有以下索引的表：

   Friends ( user_id1 ,user_id2) 

user_id1并且user_id2是user表的外键

1. 这些是等价的吗？如果不是，那为什么？

   Index(user_id1,user_id2) and Index(user_id2,user_id1)
   

   Run Code Online (Sandbox Code Playgroud)

2. 如果我创建主键(user_id1,user_id2)，它会自动为它创建索引吗？

   如果第一个问题中的索引不相等，那么在上面的主键命令上创建了哪个索引？

我正在使用 PostgreSQL (9.4) 数据库在 Ruby on Rails 中开发应用程序。对于我的用例，表中的列将被非常频繁地查找，因为应用程序的重点是在模型上搜索非常具体的属性。

我目前正在决定是对列使用integer类型还是简单地使用典型的字符串类型（例如character varying(255)，这是 Rails 中的默认值），因为我不确定索引上的性能差异是什么。

这些列是 enums。对于它们可以拥有的可能值的数量，它们具有固定的大小。大多数枚举长度不超过 5，这意味着索引在应用程序的整个生命周期中或多或少是固定的；因此，整数和字符串索引在节点数上是相同的。

但是，将被索引的字符串可能有大约 20 个字符长，在内存中大约是整数的 5 倍（如果一个整数是 4 个字节，并且字符串是纯 ASCII 每个字符 1 个字节，那么这成立）。我不知道数据库引擎如何进行索引查找，但是如果它需要“扫描”字符串直到它完全匹配，那么本质上这意味着字符串查找将比整数查找慢 5 倍；整数查找匹配之前的“扫描”将是 4 个字节而不是 20 个。这就是我的想象：

查找值为（整数）4：

扫描………………………………………………………………………………………………………………………………………… 正在获取记录... |BYTE_1|BYTE_2|BYTE_3|BYTE_4|BYTE_5|BYTE_6|BYTE_7|BYTE_8|...|

查找值是（字符串）“some_val”（8 个字节）：

扫描................................................. …………………………………………………………………………………………………………………………………………………………………… 正在获取记录... |BYTE_1|BYTE_2|BYTE_3|BYTE_4|BYTE_5|BYTE_6|BYTE_7|BYTE_8|...|

我希望这是有道理的。基本上，因为整数占用更少的空间，它可以比它的字符串对应物更快地“匹配”。也许这是一个完全错误的猜测，但我不是专家，所以这就是我问你们的原因！我想我刚刚找到的这个答案似乎支持我的假设，但我想确定一下。

列中可能值的数量在使用任何一个时都不会改变，因此索引本身不会改变（除非我向枚举添加了一个新值）。在这种情况下，使用integeror会有性能差异varchar(255)，还是使用整数类型更有意义？

我问的原因是 Rails 的enum类型将整数映射到字符串键，但它们并不是面向用户的列。本质上，您无法验证枚举值是否有效，因为无效值会ArgumentError在运行任何验证之前导致。使用string类型将允许验证，但如果存在性能成本，我宁愿绕过验证问题。

我有一个带有多列索引的表，我怀疑索引的正确排序以获得最大查询性能。

场景：

• PostgreSQL 8.4，大约有一百万行的表

• c1列中的值可以有大约100 个不同的值。我们可以假设这些值是均匀分布的，因此每个可能的值大约有 10000 行。

• 列c2可以有1000 个不同的值。对于每个可能的值，我们有 1000 行。

搜索数据时，条件始终包含这两列的值，因此该表具有组合 c1 和 c2 的多列索引。如果您的查询仅使用一列进行过滤，我已经阅读了正确排序多列索引中的列的重要性。在我们的场景中，情况并非如此。

我的问题是这个：

鉴于其中一个过滤器选择的数据集要小得多，如果第一个索引是最具选择性的索引（允许更小的数据集），我是否可以提高性能？在我看到参考文章中的图形之前，我从未考虑过这个问题：

图片取自有关多列索引的参考文章。

查询使用两列中的值进行过滤。我没有仅使用一列进行过滤的查询。他们都是：WHERE c1=@ParameterA AND c2=@ParameterB。还有这样的条件：WHERE c1 = "abc" AND c2 LIKE "ab%"

我正在运行 PostgresSQL 9.2 并且有一个 12 列的关系，大约有 6,700,000 行。它包含 3D 空间中的节点，每个节点都引用一个用户（创建它的人）。要查询哪个用户创建了多少个节点，我执行以下操作（添加explain analyze以获取更多信息）：

EXPLAIN ANALYZE SELECT user_id, count(user_id) FROM treenode WHERE project_id=1 GROUP BY user_id;
                                                    QUERY PLAN                                                         
---------------------------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=253668.70..253669.07 rows=37 width=8) (actual time=1747.620..1747.623 rows=38 loops=1)
   ->  Seq Scan on treenode  (cost=0.00..220278.79 rows=6677983 width=8) (actual time=0.019..886.803 rows=6677983 loops=1)
         Filter: (project_id = 1)
 Total runtime: 1747.653 ms

如您所见，这大约需要 1.7 秒。考虑到数据量，这还算不错，但我想知道这是否可以改进。我尝试在用户列上添加 BTree 索引，但这没有任何帮助。

您有其他建议吗？

为了完整起见，这是完整的表定义及其所有索引（没有外键约束、引用和触发器）：

    Column     |           Type           |                      Modifiers                    
---------------+--------------------------+------------------------------------------------------
 id            | bigint                   | not null default nextval('concept_id_seq'::regclass)
 user_id       | bigint …

我想从Postgres 文档中询问这个片段关于varchar(n)类型的含义：

短字符串（最多 126 个字节）的存储要求是 1 个字节加上实际字符串，其中包括字符情况下的空格填充。较长的字符串有 4 个字节的开销而不是 1 个字节。

假设我有一个varchar(255)字段。现在，以下声明：

• 如果该字段包含 10 个字节的字符串，则开销为 1 个字节。因此该字符串将使用 11 个字节。
• 如果该字段使用 140 个字节保存字符串，则开销为 4 个字节。因此该字符串将使用 144 个字节。

上面的那些说法是真的吗？这里有人理解文档相同的方式，我不过这里有人指出的开销总是4个字节在这里？

是的，我知道数据规范化应该是我的首要任务（因为它是）。

1. 我有一个表，65列存储与列车辆数据：used_vehicle，color，doors，mileage，price等等，总共65。
2. 现在，我可以将它分开并有一个Vehicle表，VehicleInterior, VehicleExterior, VehicleTechnical, VehicleExtra（与主Vehicle表一一对应）。

假设我将有大约 500 万行（车辆）。

在SELECT一个WHERE条款：请问性能会更好，通过搜索（至少索引的这两种情况下IDs）：

1. Vehicle 具有 65 列的表或
2. Vehicle表与JOINS其他四个表（均具有 500 万行）以返回与Vehicle?

（根据数据库引擎，考虑 PostgreSQL 和/或 MySQL）。

真的很感激您从以前的经验中可能获得的任何详细见解吗？

如果有的话，更新将很少见，并且选择将主要针对搜索结果列表的所有列（车辆详细信息页面）和主要信息（几列），实际上也许最好的解决方案是两个表：一个包含主要信息（很少列）和另一个表以及其余的列。

我正在使用 Postgres 9.3.5 并且我在数据库中有一个大表，目前它有超过 2500 万行，而且它往往会迅速变大。我正在尝试使用一个简单的查询来选择特定的行（所有unit_ids 都只有最新unit_timestamp的），例如：

SELECT unit_id, max(unit_timestamp) AS latest_timestamp FROM all_units GROUP BY unit_id;

在没有任何索引的情况下，此查询大约需要 35 秒才能执行。定义索引 ( CREATE INDEX partial_idx ON all_units (unit_id, unit_timestamp DESC);) 后，查询时间缩短到（仅）19 秒左右。

我想知道是否有可能在更短的时间内（比如几秒钟）执行我的查询，如果是这样，我应该采取哪些步骤来进一步优化它？

我的表结构转储如下所示：

CREATE TABLE "all_units" (
"unit_id" int4 NOT NULL,
"unit_timestamp" timestamp(6) NOT NULL,
"lon" float4,
"lat" float4,
"speed" float4,
"status" varchar(255) COLLATE "default"
)
ALTER TABLE "all_units" ADD PRIMARY KEY ("unit_id", "unit_timestamp");

该EXPLAIN (ANALYZE, BUFFERS)如下：

QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------
HashAggregate  (cost=663998.38..664069.73 rows=7135 …

我有一个包含 720 万个元组的表，如下所示：

                               table public.methods
 column |          type         |                      attributes
--------+-----------------------+----------------------------------------------------
 id     | integer               | not null DEFAULT nextval('methodkey'::regclass)
 hash   | character varying(32) | not null
 string | character varying     | not null
 method | character varying     | not null
 file   | character varying     | not null
 type   | character varying     | not null
Indexes:
    "methods_pkey" PRIMARY KEY, btree (id)
    "methodhash" btree (hash)

现在我想选择一些值，但查询速度非常慢：

db=# explain 
    select hash, string, count(method) 
    from methods 
    where hash not in 
          (select hash from nostring) …