标签: performance

我有一个带有两个表的 sqlite 数据库，每个表有 50,000 行，包含（假）人的名字。我构建了一个简单的查询来找出有多少个名字（名字、中间名首字母、姓氏）是两个表共有的：

select count(*) from fakenames_uk inner join fakenames_usa on fakenames_uk.givenname=fakenames_usa.givenname and fakenames_uk.surname=fakenames_usa.surname and fakenames_uk.middleinitial=fakenames_usa.middleinitial;

当除了主键上没有索引（与此查询无关）时，它运行得很快：

[james@marlon Downloads] $ time sqlite3 generic_data_no_indexes.sqlite "select count(*) from fakenames_uk inner join fakenames_usa on fakenames_uk.givenname=fakenames_usa.givenname and fakenames_uk.surname=fakenames_usa.surname and fakenames_uk.middleinitial=fakenames_usa.middleinitial;"
131

real    0m0.115s
user    0m0.111s
sys     0m0.004s

但是如果我为每个表的三列添加索引（总共六个索引）：

CREATE INDEX `idx_uk_givenname` ON `fakenames_uk` (`givenname` )
//etc.

然后它运行得很慢：

[james@marlon Downloads] $ time sqlite3 generic_data.sqlite "select count(*) from fakenames_uk inner join fakenames_usa on fakenames_uk.givenname=fakenames_usa.givenname and fakenames_uk.surname=fakenames_usa.surname and fakenames_uk.middleinitial=fakenames_usa.middleinitial;"
131

real    1m43.102s
user    0m52.397s
sys …

我station_logs在 PostgreSQL 9.6 数据库中有一个表：

    Column     |            Type             |    
---------------+-----------------------------+
 id            | bigint                      | bigserial
 station_id    | integer                     | not null
 submitted_at  | timestamp without time zone | 
 level_sensor  | double precision            | 
Indexes:
    "station_logs_pkey" PRIMARY KEY, btree (id)
    "uniq_sid_sat" UNIQUE CONSTRAINT, btree (station_id, submitted_at)

我试图level_sensor根据submitted_at, 对于每个station_id. 大约有 400 个唯一station_id值，每个station_id.

创建索引之前：

EXPLAIN ANALYZE
SELECT DISTINCT ON(station_id) station_id, submitted_at, level_sensor
FROM station_logs ORDER BY station_id, submitted_at DESC;

 唯一（成本=4347852.14..4450301.72行=89宽度=20）（实际时间=22202.080..27619.167行=98循环=1）
   -> Sort …

我是埃因霍温 Fontys 大学的学生，我目前正在进行一系列采访以帮助开发 SQL Server 工具，我想从该领域的专家那里得到反馈。

我的问题之一是：

您在使用 SQL Server 实例时遇到的前 3 个性能问题是什么？您如何确定这些问题？

我对用于衡量这一点的脚本和工具特别感兴趣。

我的问题是关于索引的使用。

1. 我应该从一开始还是在出现性能问题时开始索引？

2. 我们还可以在执行查询时创建临时索引。这种技术的优缺点是什么？

相当简单的问题，可能在某处得到了回答，但我似乎无法为 Google 形成正确的搜索问题......

在查询该表的子集时，特定表中的列数是否会影响查询的性能？

例如，如果表 Foo 有 20 列，但我的查询只选择了其中的 5 列，那么有 20（而不是 10）列会影响查询性能吗？为简单起见，假设 WHERE 子句中的任何内容都包含在这 5 列中。

除了操作系统的磁盘缓存之外，我还担心 Postgres 的缓冲区缓存的使用。我对 Postgres 的物理存储设计一无所知。表存储在多个页面上（默认为每页 8k 大小），但我不太明白元组是如何从那里排列的。PG 是否足够聪明，只能从磁盘中获取包含这 5 列的数据？

在诊断基数估计不佳的 SQL Server 2008 R2 查询（尽管有简单的索引、最新的统计数据等）和查询计划不佳时，我发现了一篇可能相关的知识库文章： FIX：运行查询时性能不佳包含 SQL Server 2008 或 SQL Server 2008 R2 或 SQL Server 2012 中的关联 AND 谓词

我可以猜测知识库文章中“相关”的含义，例如谓词#2 和谓词#1 主要针对相同的行。

但我不知道 SQL Server 是如何知道这些相关性的。表是否需要包含来自两个谓词的列的多列索引？SQL 是否使用统计信息来检查一列中的值是否与另一列相关？还是使用了其他方法？

我问这个有两个原因：

1. 确定使用此修补程序可以改进我的哪些表和查询
2. 知道我应该在索引、统计等方面做些什么来影响 #1

array列有上限吗？

插入数组字段时出现此错误 -

PG::Error: ERROR:  index row size 3480 exceeds maximum 2712 for index "ix_data"

这是我的表定义 -

create table test_array(id varchar(50), data text[]);

ALTER TABLE test_array ADD PRIMARY KEY (id);

CREATE INDEX ix_data ON test_array USING GIN (data);

我需要数组字段的索引，因为我正在对它进行一些查找。

在某些情况下，需要非常大的查询将多个表与其中的子选择语句连接在一起以产生所需的结果。

我的问题是，我们是否应该考虑使用多个较小的查询，并通过多次调用查询数据库将逻辑操作带入应用程序层，还是最好一次性完成所有操作？
例如，考虑以下查询：

SELECT *
FROM   `users`
WHERE  `user_id` IN (SELECT f2.`friend_user_id`
                     FROM   `friends` AS f1
                            INNER JOIN `friends` AS f2
                              ON f1.`friend_user_id` = f2.`user_id`
                     WHERE  f2.`is_page` = 0
                            AND f1.`user_id` = "%1$d"
                            AND f2.`friend_user_id` != "%1$d"
                            AND f2.`friend_user_id` NOT IN (SELECT `friend_user_id`
                                                            FROM   `friends`
                                                            WHERE  `user_id` = "%1$d"))
       AND `user_id` NOT IN (SELECT `user_id`
                             FROM   `friend_requests`
                             WHERE  `friend_user_id` = "%1$d")
       AND `user_image` IS NOT NULL
ORDER  BY RAND() 
LIMIT %2$d

最好的方法是什么？

我正在尝试确定哪些索引用于带有WHERE条件的 SQL 查询，GROUP BY而当前运行速度很慢。

我的查询：

SELECT group_id
FROM counter
WHERE ts between timestamp '2014-03-02 00:00:00.0' and timestamp '2014-03-05 12:00:00.0'
GROUP BY group_id

该表目前有 32.000.000 行。当我增加时间范围时，查询的执行时间会增加很多。

有问题的表如下所示：

CREATE TABLE counter (
    id bigserial PRIMARY KEY
  , ts timestamp NOT NULL
  , group_id bigint NOT NULL
);

我目前有以下索引，但性能仍然很慢：

CREATE INDEX ts_index
  ON counter
  USING btree
  (ts);

CREATE INDEX group_id_index
  ON counter
  USING btree
  (group_id);

CREATE INDEX comp_1_index
  ON counter
  USING btree
  (ts, group_id);

CREATE INDEX comp_2_index
  ON counter …

我正在使用 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 …