【问题标题】:Slow query in postgresqlpostgresql中的慢查询
【发布时间】:2015-03-13 03:29:29
【问题描述】:

我对一个表有一个简单的查询,问题是性能缓慢。 这是表定义:

-- Table: variable_logs

CREATE TABLE variable_logs
(
  id serial NOT NULL,
  variable_id integer,
  created_at timestamp without time zone,
  updated_at timestamp without time zone,
  "timestamp" timestamp without time zone,
  value character varying(255)[] DEFAULT '{}'::character varying[],
  CONSTRAINT variable_logs_pkey PRIMARY KEY (id)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE variable_logs
  OWNER TO postgres;
ALTER TABLE variable_logs ALTER COLUMN created_at SET STATISTICS 1000;


-- Index: idx_time_limits_inversed

-- DROP INDEX idx_time_limits_inversed;

CREATE INDEX idx_time_limits_inversed
  ON variable_logs
  USING btree
  (variable_id, created_at DESC);

基本上是我每 X 次(例如:10 秒)保存一次数据的表,并且它正在迅速增长。 “值”列在数组中每行只有 1 个元素。

Postgresql 版本是:“x86_64-unknown-linux-gnu 上的 PostgreSQL 9.1.14,由 gcc (Ubuntu/Linaro 4.8.1-10ubuntu8) 4.8.1 编译,64 位”

现在该表大约有 653941 行,并且对该表的查询(没有任何连接)很慢。

SELECT   variable_logs.created_at, variable_logs.variable_id, variable_logs.value
FROM variable_logs 
WHERE variable_logs.variable_id = 2
AND (variable_logs.created_at BETWEEN '2015-01-01 00:00:00.000000'
                                  AND '2015-03-09 23:59:00.000000')
ORDER BY created_at asc

Total query runtime: 13979 ms.
184369 rows retrieved.

如果我执行相同的查询而没有顺序并过滤日期:

SELECT variable_logs.created_at, variable_logs.variable_id, variable_logs.value 
FROM variable_logs 
WHERE variable_logs.variable_id = 2

Total query runtime: 14035 ms.
184369 rows retrieved.

查询总是很慢,我也尝试用同样慢的结果执行 VACUUM 和 ANALYZE。

EXPLAIN (ANALYZE on, VERBOSE off, COSTS on, BUFFERS on)
SELECT variable_logs.created_at, variable_logs.variable_id, variable_logs.value 
FROM variable_logs 
WHERE variable_logs.variable_id = 2 
  AND (variable_logs.created_at BETWEEN '2015-01-01 00:00:00.000000'  
                                    AND '2015-03-09 23:59:00.000000')  
ORDER BY created_at asc;

"Sort  (cost=32374.66..32835.00 rows=184137 width=53) (actual time=150.983..160.467 rows=184369 loops=1)"
"  Sort Key: created_at"
"  Sort Method: quicksort  Memory: 27833kB"
"  Buffers: shared hit=8570"
"  ->  Bitmap Heap Scan on variable_logs  (cost=5188.10..16271.50 rows=184137 width=53) (actual time=33.239..70.201 rows=184369 loops=1)"
"        Recheck Cond: ((variable_id = 2) AND (created_at >= '2015-01-01 00:00:00'::timestamp without time zone) AND (created_at <= '2015-03-09 23:59:00'::timestamp without time zone))"
"        Buffers: shared hit=8570"
"        ->  Bitmap Index Scan on idx_time_limits_inversed  (cost=0.00..5142.06 rows=184137 width=0) (actual time=31.935..31.935 rows=184369 loops=1)"
"              Index Cond: ((variable_id = 2) AND (created_at >= '2015-01-01 00:00:00'::timestamp without time zone) AND (created_at <= '2015-03-09 23:59:00'::timestamp without time zone))"
"              Buffers: shared hit=709"
"Total runtime: 170.038 ms"

我尝试按照https://wiki.postgresql.org/wiki/Slow_Query_Questions 的“发布前要尝试的事项”指南更改 postgres.conf 的配置,但没有成功;(

【问题讨论】:

  • 乍一看,主要是最后的order by date_created(->排序步骤)让它“慢”。
  • 请在此处包含问题中的相关信息。不要链接到外部资源。
  • @wildplasser 如果我删除排序顺序,它是相同的;(.. 如果我执行相同的查询没有顺序并过滤日期:SELECT variable_logs.created_at,variable_logs.variable_id,variable_logs.value FROM variable_logs WHERE variable_logs.variable_id = 2 总查询运行时间:14035 毫秒。检索到 184369 行。
  • Total runtime: 170.038 ms" 是您的慢查询?
  • @wildplasser 170.038 是查询“EXPLAIN (ANALYZE on, VERBOSE off, COSTS on, BUFFERS on)”的时间

标签: performance postgresql postgresql-9.1


【解决方案1】:

您正在检索表中 23% 的行。我不认为使用索引会有好处,除非它涵盖了查询所需的所有列并提供了所需的排序顺序。

尝试不使用索引,然后在 (variable_id, created_at, value) 上添加索引

【讨论】:

  • 没有索引的相同查询:总查询运行时间:14575 毫秒。检索到 184369 行。
  • 在 (variable_id, created_at, value) 上具有索引的相同查询需要总查询运行时间:14420 毫秒。 ;(
  • 你最好也显示解释分析结果。
  • EXPLAIN (ANALYZE on, VERBOSE off, COSTS on, BUFFERS on) query.... "对 plc_engine_variable_logs 的 Seq Scan (cost=0.00..19363.27 rows=183810 width=53) (实际时间= 0.027..147.689 行=184369 循环=1)"" 过滤器: ((created_at >= '2015-01-01 00:00:00'::timestamp without time zone) AND (created_at
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多