【问题标题】:Django PostgreSQL double index cleanupDjango PostgreSQL 双索引清理
【发布时间】:2021-02-05 16:01:44
【问题描述】:

我们的数据库中有这张表,其中包含 80GB 的数据和 230GB 的索引。我们被限制在已经被最大化的磁盘上。

困扰我的是我们有两个看起来非常相似的索引

 CREATE        INDEX tracks_trackpoint_id   ON tracks_trackpoint USING btree (id)   
 CREATE UNIQUE INDEX tracks_trackpoint_pkey ON tracks_trackpoint USING btree (id)

我不知道这背后的历史是什么,但第一个似乎是多余的。丢弃它有什么风险?这将为我们购买一年的存储空间。

【问题讨论】:

  • 我知道第二个索引可能是由于与另一个模型的多对多关系而自动创建的,但是该模型仍然对 pkey 索引感到满意吗?,性能方面?

标签: django postgresql indexing


【解决方案1】:

你可以删除第一个索引,它完全是多余的。

如果您的表为 80GB,索引为 230GB,我敢打赌,您的数据库中的索引太多了。

Drop the indexes that are not used.

【讨论】:

  • 谢谢你,你让我的信心进一步增强,我真的记得不久前读过你的文章,并且已经在大索引上下降了。
  • 根据您文章中的查询,该索引不是 UNUSED。看起来很多余。
  • 我们有关于时间戳的第三个索引,如果您需要短时间内的所有跟踪点,这很有意义。那是。另外42GB。还有一个是trackid和timestamp,还有一个41GB。还有一个单独的track id,37GB。这可能与前者相比是多余的,一旦你在跟踪日志中获得了 +- 2k 点,在一个时期内获得这个点就容易了几个数量级
  • 好吧,对于那个我应该反过来想,trackid和timestamp上的那个实际上可以返回具有特定trackid的所有记录。
【解决方案2】:

虽然我很小心,但我禁用了索引来对此进行基准测试,并且查询似乎很好地回退到另一个索引上。我会尝试一些变体。

appdb=# EXPLAIN analyze SELECT * FROM tracks_trackpoint where id=266082;
 Index Scan using tracks_trackpoint_id on tracks_trackpoint  (cost=0.57..8.59 rows=1 width=48) (actual time=0.013..0.013 rows=0 loops=1)
   Index Cond: (id = 266082)
 Total runtime: 0.040 ms
(3 rows)

appdb=# UPDATE pg_index SET indisvalid = FALSE WHERE indexrelid = 'tracks_trackpoint_id'::regclass;

appdb=# EXPLAIN analyze SELECT * FROM tracks_trackpoint where id=266082;
 Index Scan using tracks_trackpoint_pkey on tracks_trackpoint  (cost=0.57..8.59 rows=1 width=48) (actual time=0.013..0.013 rows=0 loops=1)
   Index Cond: (id = 266082)
 Total runtime: 0.036 ms
(3 rows)

【讨论】:

  • 我刚刚杀死了索引,一切都运行良好
猜你喜欢
  • 1970-01-01
  • 2013-01-20
  • 2019-07-16
  • 2021-06-27
  • 2021-12-25
  • 1970-01-01
  • 2018-07-22
  • 2017-09-20
  • 1970-01-01
相关资源
最近更新 更多