相关疑难解决方法(0)

我必须编写一个简单的查询，在其中查找以 B 或 D 开头的人名：

SELECT s.name 
FROM spelers s 
WHERE s.name LIKE 'B%' OR s.name LIKE 'D%'
ORDER BY 1

我想知道是否有办法重写它以提高性能。所以我可以避免or和/或like？

我有一个包含大量插入内容的表，将其中一个字段 ( uploaded_at) 设置为NULL. 然后周期性任务选择所有元组WHERE uploaded_at IS NULL，处理它们并更新，设置uploaded_at为当前日期。

我应该如何索引表？

我知道我应该使用部分索引，例如：

CREATE INDEX foo ON table (uploaded_at) WHERE uploaded_at IS NULL

或者像那样。我有点困惑，但如果在始终为NULL. 或者如果使用 b 树索引是正确的。Hash 看起来是一个更好的主意，但它已经过时并且不能通过流式热备复制进行复制。任何建议将不胜感激。

我对以下索引进行了一些试验：

"foo_part" btree (uploaded_at) WHERE uploaded_at IS NULL
"foo_part_id" btree (id) WHERE uploaded_at IS NULL

并且查询平面似乎总是选择foo_part索引。索引的explain analyse结果也稍好一些foo_part：

Index Scan using foo_part on t1  (cost=0.28..297.25 rows=4433 width=16) (actual time=0.025..3.649 rows=4351 loops=1)
   Index Cond: (uploaded_at IS NULL)
 Total runtime: 4.060 ms

对比 …

我有一个 PostgreSQL 9.3 表，其中包含一些数字和一些附加数据：

CREATE TABLE mytable (
    myid BIGINT,
    somedata BYTEA
)

该表目前有大约 10M 条记录，占用 1GB 磁盘空间。myid不连续。

我想计算 100000 个连续数字的每个块中有多少行：

SELECT myid/100000 AS block, count(*) AS total FROM mytable GROUP BY myid/100000;

这将返回大约 3500 行。

我注意到某个索引的存在显着加快了这个查询，即使查询计划根本没有提到它。没有索引的查询计划：

db=> EXPLAIN (ANALYZE TRUE, VERBOSE TRUE) SELECT myid/100000 AS block, count(*) AS total FROM mytable GROUP BY myid/100000;
                                                               QUERY PLAN                                                               
----------------------------------------------------------------------------------------------------------------------------------------
 GroupAggregate  (cost=1636639.92..1709958.65 rows=496942 width=8) (actual time=6783.763..8888.841 rows=3460 loops=1)
   Output: ((myid / 100000)), count(*)
   ->  Sort  (cost=1636639.92..1659008.91 rows=8947594 width=8) (actual time=6783.752..8005.831 …

我对数据库进行基准测试以找出最适合我的项目的数据库，我发现这count(*)在 PostgeSQL 中非常慢。我不明白这是 PostgeSQL 的正常行为还是我做错了什么。

我有一个包含 ~200M 记录的表。MySQL表定义：

CREATE TABLE t1 (
  id int(11) NOT NULL AUTO_INCREMENT,
  t2_id int(11) NOT NULL,
....  
  PRIMARY KEY (id),
  KEY index_t2 (t2_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

请求（返回~30M）：

SELECT COUNT(*) FROM t1 WHERE t2_id = 7;

运行：

25,797ms MySQL (v5.7.11)

1,222,168ms PostgeSQL (v9.5)

解释：

MySQL：

*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: t1
   partitions: NULL
         type: ref
possible_keys: index_t2
          key: index_t2
      key_len: 4
          ref: const
         rows: 59438630
     filtered: 100.00
        Extra: Using …

Postgres 版本

使用 PostgreSQL 10.3。

表定义

CREATE TABLE tickets (
  id bigserial primary key,
  state character varying,
  closed timestamp
);

CREATE INDEX  "state_index" ON "tickets" ("state")
  WHERE ((state)::text = 'open'::text));

基数

该表包含 1027616 行，其中 51533 行具有state = 'open'和closed IS NULL或 5%。

条件为 on 的查询state按预期使用索引扫描执行良好：

explain analyze select * from tickets where state = 'open';

Index Scan using state_index on tickets  (cost=0.29..16093.57 rows=36599 width=212) (actual time=0.025..22.875 rows=37346 loops=1)
Planning time: 0.212 ms
Execution time: 25.697 …