Django基于PostgreSQL的冗余id字段btree索引清理风险问询

• 运行环境：Django框架搭载PostgreSQL数据库的生产业务系统
• 当前存储状态：核心表tracks_trackpoint单表数据量达80GB，关联索引总大小230GB，磁盘空间已100%占满，存储资源完全耗尽
• 发现的疑似冗余索引：两个基于id列创建的结构完全相同的btree索引
  • 普通非唯一索引：tracks_trackpoint_id，创建语句为 CREATE INDEX tracks_trackpoint_id ON tracks_trackpoint USING btree (id)
  • 主键唯一索引：tracks_trackpoint_pkey，创建语句为 CREATE UNIQUE INDEX tracks_trackpoint_pkey ON tracks_trackpoint USING btree (id)
• 收益预期：普通索引tracks_trackpoint_id被判定为冗余对象，删除后释放的存储空间可支撑系统约1年的存储增长需求

• 索引来源未溯源的隐含依赖风险
  • 未排查ORM层硬依赖：部分Django项目会在模型的Meta配置中，显式为id字段单独声明非唯一索引。若直接删除该索引，后续执行Django迁移命令时会检测到索引缺失，触发自动重建逻辑——在当前磁盘完全占满的场景下，重建过程会因无写入空间直接卡死迁移流程，甚至拖垮整个数据库实例
  • 未排查查询层硬依赖：部分自定义原生SQL可能通过查询提示，强制指定走tracks_trackpoint_id索引。删除后这类SQL会直接执行报错，或者被迫走全表扫描，引发业务性能雪崩
• 满磁盘场景下的操作执行风险
  • 普通DROP INDEX会持有目标表的排他锁，如果数据库中存在持有该表读锁的长事务，删除操作会阻塞在锁等待队列中，后续所有访问tracks_trackpoint表的业务请求都会被依次堵住，直接引发线上服务中断
  • 不要默认删除后立刻回收全部磁盘空间：PostgreSQL删除索引只是将索引标记为可复用状态，实际的磁盘空间释放需要等待后续的空间回收流程，而完全占满的磁盘甚至可能连删除操作所需的临时事务日志写入空间都不够，导致删除命令直接执行失败
• 结构误判带来的性能损失风险
  • 仅靠建表语句对比无法确认索引的实际结构：如果后续对主键索引做过修改（比如追加INCLUDE列做成覆盖索引、添加部分行过滤条件），两个索引的实际用途并不等价；如果排查不仔细误删了带覆盖属性的索引，会直接导致一大批依赖覆盖索引的查询性能暴跌
  • 老版本PostgreSQL的查询优化器对普通索引和主键索引的执行计划选择存在差异：比如并行扫描的触发阈值、索引顺序扫描的成本计算规则并不完全一致，删除普通索引后对应高频查询的执行计划可能出现预期外的性能下滑

• 通过pg_indexes系统表导出两个索引的完整定义，逐字段对比索引列、排序规则、过滤条件、INCLUDE列，确认二者完全等价，不存在结构差异
• 全局检索Django项目的模型定义、迁移文件、原生SQL代码，确认没有任何硬编码逻辑依赖tracks_trackpoint_id这个索引对象
• 执行前预留至少2GB的临时磁盘空间，避免事务日志写入失败
• 选择业务低峰期使用DROP INDEX CONCURRENTLY语法删除，同时设置合理的锁超时参数，避免长时间阻塞业务

内容的提问来源于stack exchange，提问作者nmajoros