Django PostgreSQL双索引清理

我们的数据库中有一个表，包含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)

---

我不知道这背后的历史是什么，但第一个似乎是多余的。掉下来的风险有多大？这将为我们购买一年的存储空间。

您可以删除第一个索引，它完全是多余的

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

---

尽管我很小心，但我禁用了索引来对此进行基准测试，查询似乎很好地回退到了另一个索引上。我将尝试一些变体

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)

---

我知道第二个索引可能是自动创建的，因为它与另一个模型有很多关系，但该模型是否仍然对pkey索引感到满意？性能方面？谢谢，您进一步提高了我的信心，事实上，我记得不久前读过你的文章，并且已经在大索引上下了手。根据你文章中的查询，这个索引并没有被使用。它看起来很冗余。我们有一个关于时间戳的第三个索引，如果你在短时间内需要所有跟踪点，这是有意义的。那一个是。另外42GB。一个是trackid和timestamp，另一个是41GB。仅轨道id上还有一个，37GB。这一个可能与前一个是多余的，一旦你在轨迹日志中得到+-2k点，得到它。一个周期是数量级的简单，对于这个周期，我应该反过来想，在trackid和timestamp上的一个实际上可以返回具有特定trackid的所有记录。我刚刚删除了索引，一切都正常运行