PostgreSQL删除重复数据保留一条的CTID方法详解

在数据维护中，遇到重复记录需要清理是常事。直接用 ctid 配合子查询删除，思路直接，但必须清楚它的适用边界：这只适合一次性清理、无并发写入、且不依赖物理位置稳定性的场景。否则，很容易踩坑，导致误删或漏删。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

为什么 ctid 能用来去重？

ctid 是 PostgreSQL 为每行记录分配的一个物理位置标识，由块号和偏移量组成。只要没有执行 VACUUM FULL 或表重建，同一行的这个标识就是不变的。它天生唯一，而且比逻辑主键更“底层”，即使表没有定义主键也能用它来定位。

不过，ctid 终究不是逻辑唯一键。当一行数据被更新后，可能会产生一个新的 ctid，而旧版本可能还留在磁盘上等待清理。此外，VACUUM 操作也可能导致 ctid 重新排列。因此，它只适用于“基于当前数据快照进行临时去重”的场景。

• 适合场景：导入脏数据后的清洗、测试库的快速去重、无主键的小表处理。
• 不适合场景：生产环境中频繁更新的表、涉及逻辑复制或订阅的表、需要根据业务时间保留“最新”记录的情况（因为 ctid 小并不绝对代表插入时间早或数据新）。

DELETE ... WHERE ctid NOT IN (SELECT MIN(ctid) ...) 的潜在问题

这个写法看起来简洁明了，但在实际执行时，有几个细节容易出问题：

• NULL 值陷阱：当 NOT IN 子句中的子查询结果包含 NULL 时，整个条件会返回空集，导致一条记录都删不掉。如果分组字段允许为 NULL，虽然 GROUP BY 后 MIN(ctid) 仍能正常计算，但如果在子查询中误加了类似 WHERE col IS NOT NULL 的条件，就可能意外引入 NULL 风险。
• 分组字段必须精确匹配：子查询中 GROUP BY 的字段，必须与判定重复的字段完全一致。少一个字段，分组粒度变粗，可能保留了重复项；多一个字段，分组粒度变细，可能把不该去重的行也拆开了。
• 大表性能压力：对于大表，执行 SELECT MIN(ctid) FROM t GROUP BY a,b 会触发全表扫描和哈希分组，对内存消耗较大。如果相关字段上没有索引，查询速度会非常慢。

一个相对稳妥的写法示例如下（假设对 users 表按 email 字段去重）：

DELETE FROM users
WHERE ctid NOT IN (
  SELECT MIN(ctid)
  FROM users
  WHERE email IS NOT NULL  -- 显式排除 NULL，避免 NOT IN 失效
  GROUP BY email
);

想保留“最新插入”或“最新修改”的那条？别只依赖 ctid

通常认为 ctid 值小代表插入时间早，但这个规律并不绝对。批量数据导入（COPY）、事务回滚、或者堆内元组（HOT）更新等技术，都可能导致新插入的行获得更小的 ctid。因此，若想真正保留业务上“最新”的记录，必须依赖明确的时间字段，例如 created_at 或 updated_at。

这时，窗口函数是比单纯依赖 ctid 更可靠的选择：

WITH ranked AS (
  SELECT id, ctid,
         ROW_NUMBER() OVER (
           PARTITION BY email
           ORDER BY updated_at DESC, id DESC
         ) AS rn
  FROM users
  WHERE email IS NOT NULL
)
DELETE FROM users
WHERE ctid IN (SELECT ctid FROM ranked WHERE rn > 1);

• 这个思路是用 ctid 作为最终的删除锚点，但决定保留哪一行的排序依据是明确的业务时间字段（updated_at），兼顾了语义准确性和执行效率。
• 在 ORDER BY 子句中加入 id DESC 是为了在时间戳相同的情况下，提供一个确定性的排序规则，避免因执行计划不同而导致结果不一致。
• 务必在 email 和 updated_at 字段上建立复合索引，否则窗口函数的计算（OVER）在大数据量下会非常缓慢。

说到底，真正的难点往往不在于语法本身，而在于如何精确地定义“重复”。是否需要考虑所有 NULL 值的组合？是否要忽略大小写或首尾空格？这些业务逻辑一旦需要融入 GROUP BY 或 PARTITION BY 中，就很难再通过 ctid 这类物理标识来补救。事先明确规则，远比事后补救要高效得多。