深入理解PostgreSQL DELETE：MVCC逻辑与VACUUM清理优化

1. 先说一次让我改观 DELETE 的线上故障

1.1 一条简单的清理任务，为什么把库拖垮了？

有段时间我维护过一套基于 PostgreSQL 的业务系统，每天凌晨有定时任务，要从一张流水表里删除 30 天之前的历史数据。最初上线时一切正常，后来随着业务量上涨，这张流水表的数据量从几千万涨到了好几亿，噩梦就来了。

那天凌晨两点，值班电话直接把我叫醒——数据库 CPU 持续打满，磁盘 IO 飙升到平时的几十倍，主库的复制延迟从几秒直接拉到了二十多分钟。一开始我怀疑是慢查询，结果翻到 pg_stat_activity，发现罪魁祸首就是那条约 DELETE 的清理语句。它不是第一次跑了，之前也删过无数次，但那天它整整跑了一个多小时都没结束，还把整个库的写入拖慢了。更夸张的是，这张表在删除期间物理文件还在持续变大。

经过这次事故，我才真正意识到：PostgreSQL 里的 DELETE 和 MySQL 里的 DELETE 不是一回事，和很多人以为的"把数据擦掉"更不是一回事。如果不理解 DELETE 在 PostgreSQL 底层到底做了什么，就算你的 SQL 语句写得很标准，照样能把生产环境搞挂。

1.2 把 DELETE 当成"写入+标记"而不是"擦除"

很多人第一次接触 PostgreSQL 时是从 MySQL 迁过来的，潜意识里会觉得 DELETE 就是找到目标行、然后物理移除。等到去查 pg_class.relpages 或者看数据目录里的堆文件，才发现删除之后磁盘占用不降反升，一脸懵。

PostgreSQL 基于 MVCC（多版本并发控制）实现事务隔离，它的最核心逻辑是：一行数据被更新或删除之后，旧版本并不会被立即物理清理，而是先保留在堆文件里，通过 xmin/xmax 这些系统字段来标记它的可见性范围。DELETE 的本质，其实就是把目标 tuple（行版本）的 xmax 设置为当前事务 ID，同时生成一条新的 WAL 记录，告诉其他事务"这条记录从此刻开始不可见了"。

这带来两个关键影响：第一，DELETE 本身是一种"写入"，它要写 WAL、要修改页面的快照信息，所以它一点都不比 UPDATE 便宜；第二，被删除后留下的 dead tuple（死元组），必须等待 VACUUM 进程在合适的时机清理，否则表会不断膨胀。当年我遇到的"删除期间表文件越来越大"，就是因为删除产生的 dead tuple 累积速度超过了 autovacuum 的回收速度，等于一边删新数据，一边表还在被历史残留撑大。

所以，如果你要写好 PostgreSQL 的 DELETE 操作，脑子里第一根弦应该是：你的删除不是在缩小数据，而是在制造一种特殊的"历史遗留"，真正让空间恢复和性能稳定的，是删除之后的清理机制是否跟得上。

2. 从执行计划看 POSTGRES 的 DELETE 到底做了什么

2.1 DELETE 语法与最核心的"隐藏列"逻辑

先回到 DELETE 最基础的语法：

sql复制DELETE FROM table_name
[WHERE condition]
[RETURNING *];

WHERE 可加可不加。不加 WHERE 时，PostgreSQL 会清空整张表——但注意，它不是像 TRUNCATE 那样直接重建文件，而是一行一行地扫描、标记、写 WAL。对小表可能感知不明显，对几亿行的大表，这两者性能差异是数量级的。

有时候你会看到一些工具生成的清空语句是 DELETE FROM table;，如果这把表的数据量有几千万行，执行时间会非常长。为了保留数据但又想快速清空时，正确选择通常是 TRUNCATE，它通过直接修改表的存储文件来实现快速重置，但会触发表级锁，并且不能回滚单行级操作。

理解隐藏列是掌握 DELETE 的关键一步。PostgreSQL 的每个表都有几个系统列：

sql复制SELECT ctid, xmin, xmax, * FROM your_table LIMIT 3;

• ctid 表示行在磁盘页面中的物理位置；
• xmin 是插入该行版本的事务 ID；
• xmax 如果是非 0，说明该行已经被删除或更新，xmax 就是造成删除/更新的事务 ID。

一条 DELETE 语句执行时，PostgreSQL 不会立刻把数据从页面上抹掉，而是把命中行的 xmax 改成当前事务 ID。如果事务最终提交，其他事务通过可见性规则判断，发现该行的 xmax 对应的事务已经提交，那么这行数据对它们来说就是"已经删除"，查询结果里自然看不到。这个标记过程非常快，真正的代价在于：它必须对每一行目标数据都执行一次可见性检查和 xmax 更新，还需要索引同步处理。

2.2 索引要不要更新?涉及哪些锁?

DELETE 涉及索引的问题，很多人没想明白。MySQL 的 InnoDB 里，普通二级索引删除时通常要做标记删除和索引维护；PostgreSQL 则走了一条不同路线：在 DELETE 操作发生时，如果表上有二级索引，PostgreSQL 不会立刻把索引项从索引页里物理删除，而是在索引查找和可见性判断阶段，通过行头的 xmax 信息过滤掉那些已删除的行版本。

也就是说，当一个查询通过二级索引定位到某个索引项，再去堆表里取数据时，如果发现这一行的 xmax 已经指向一个已提交事务，就会认为该索引项指向的"可见版本"不存在，转而向下一行继续扫描，或者通过索引项中的 t_tid 指向较新的行版本。这套机制的副作用就是：删除操作后，索引页里同样会留下大量死条目，导致索引膨胀。

PostgreSQL 对 DELETE 加的是 ROW EXCLUSIVE 锁，这个锁与 SELECT 最常用的 ACCESS SHARE 锁不冲突，与 UPDATE/DELETE 之间会相互冲突。因此多个 DELETE 同时执行时，在行级是有冲突的，需要通过行锁或者表锁机制串行化。对于大部分普通键值删除，锁的粒度感知不强，但如果你删除时涉及大量数据并且有一个长事务始终不结束，VACUUM 就无法回收 dead tuple，后续事务的可见性判断也会越来越慢。

2.3 WAL 与崩溃恢复：删除是会被"重放"的

我之前遇到过一种误解：只要提交了 DELETE，数据库文件里那段数据就立马没有了，所以不用太在意 I/O。实际恰恰相反，无论事务大小，PostgreSQL 都会把 DELETE 生成的 WAL 记录写入预写日志。只要事务没有提交，WAL 里就有对应的删除动作；即便崩溃了，数据库重启后也会根据 WAL 做恢复。

正因如此，一次性 DELETE 大批量数据，会生成大量 WAL，这不但占用磁盘空间，还会导致流复制环境下的主从延迟。很多人把 Postgres 的批量删除运行在业务高峰期，结果从库跟不上主库的 WAL 接收速度，最后把主库的 WAL 堆积成灾。如果是不需要同步的清理任务，可以通过把 synchronous_commit 调成 off 减少一部分等待，但真正的解决思路还是得回到删除策略本身：不要在一个大事务里删太多，尽量分拆成可控的小事务。

3. 不同数据量下的删除姿势：从精准删到风暴式删除

3.1 单条/少量删除的常见误用

对单条删除，很多人会写：

sql复制DELETE FROM orders WHERE order_id = 123;

如果 order_id 是主键，这个操作非常高效，主键索引直接定位，只标记一行。但如果 WHERE 条件不是唯一键，比如：

sql复制DELETE FROM orders WHERE user_id = 456 AND status = 'canceled';

PostgreSQL 需要扫描满足条件的行，找到所有匹配项再逐一删除。最怕的是这条语句在没有合适索引的情况下执行，或者条件里的字段虽然有索引但选择性很差。这时候即便最终只删掉几百行，它为了定位这几百行，可能要把几十万甚至几百万行全部扫描一遍。

一个非常实用的技巧是：先小范围验证。在执行大批量 DELETE 前，先跑一条 SELECT count(*) 的同条件查询，估算匹配行数，同时用 EXPLAIN ANALYZE 看执行计划。如果发现 Seq Scan 且扫描行数是最终删除行数的十倍百倍以上，就得先优化索引，或者改成通过子查询定位主键 ID 再删除。否则你以为在维护数据，实际是在让数据库做无效功。

3.2 条件删除的 WHERE 设计:索引才是关键

条件删除的核心矛盾在于：WHERE 条件里的多个字段，决定了索引怎么建。假设业务上最频繁的删除操作是按照过期时间清理数据，比如：

sql复制DELETE FROM events WHERE created_at < now() - interval '30 days';

常见做法是在 created_at 上建一个 B-tree 索引。这个索引对范围扫描效果很好，问题在于，当这张表里符合"过期"条件的数据占比很高时，优化器可能会放弃索引，直接选择全表扫描，因为从磁盘读取整张表的成本可能比回表逐行验证更低。这时候实际删除的性能就会受限于表的整体大小，而不是过期数据的数量。

更好的方式是在设计表时就给清理任务留好"主键范围分段"的路径。例如不要直接删除所有 30 天前的数据，而是先查出这些数据的最小和最大主键范围，或按天分区，然后按分区 TRUNCATE。分区表的优势在这里体现得特别明显——按日期分区的表，清理旧数据时直接 DROP PARTITION，几乎不会产生大量 dead tuple，对数据库的负担小得多。

sql复制-- 如果已做表分区，可以这样做：
ALTER TABLE events DETACH PARTITION events_202401;
-- 确认数据不再需要后执行 DROP TABLE events_202401;

这套逻辑的原理是：分区 DROP 直接删除对应文件，不需要逐行标记 xmax，也不会在索引里留下死条目，是地理上最干净的清理方式。如果你的清理任务是周期性的、基于时间的，强烈建议考虑分区策略，而不是靠一条 DELETE 硬扛。

3.3 使用 USING 做关联删除，比子查询更清晰

PostgreSQL 的 DELETE 支持 FROM 和 USING 语法。很多初学者只会写子查询：

sql复制DELETE FROM orders
WHERE customer_id IN (
    SELECT id FROM customers WHERE status = 'disabled'
);

更推荐的做法是：

sql复制DELETE FROM orders
USING customers
WHERE orders.customer_id = customers.id
  AND customers.status = 'disabled';

这两种写法在语义上有细微差别，优化器可能把它们转换成不同的执行计划。实际经验是：USING 写法在关联条件复杂时更直观，而且可以利用 customers 表上的索引做哈希连接或嵌套循环连接，比简单的 IN 子查询更容易猜到优化器想要的方式。不过，当你删的是超大表并且关联字段没有索引时，USING 写法也可能产生全表扫描。因此写完 DELETE 后，最好还是用 EXPLAIN 验证。

4. 大数据量分批删除的工程化细节

4.1 分批循环的 SQL 与事务控制

如果确认无法走分区清理，只能用 DELETE 处理大批历史数据，那你千万不要一条 SQL 把所有目标行一次删完。一次 DELETE 几千万行，会带来几个连锁问题：长事务长期占住快照，阻碍 autovacuum；生成的 WAL 体积巨大；对相关表的锁持有时间过长，影响业务读写。

最稳妥的工程套路是分批处理。例如写一个循环，每次只删除一部分：

sql复制DO $$
DECLARE
    batch_size int := 5000;
    deleted_count int;
BEGIN
    LOOP
        DELETE FROM events
        WHERE ctid IN (
            SELECT ctid
            FROM events
            WHERE created_at < now() - interval '30 days'
            LIMIT batch_size
        );
        GET DIAGNOSTICS deleted_count = ROW_COUNT;
        COMMIT;
        RAISE NOTICE 'deleted % rows', deleted_count;
        EXIT WHEN deleted_count < batch_size;
        PERFORM pg_sleep(0.1);
    END LOOP;
END $$;

我见过很多人在 SQL 客户端里跑这种循环，有个坑必须提醒：匿名代码块 DO 里不能直接写 COMMIT，因为 DO 块整体运行在一个事务中。上面示例里的 COMMIT 在普通 psql 脚本里可以使用（用 \gset 或函数方式），但在 DO 块内是无效的。如果要在服务端做可控的事务循环，建议写成存储过程（PROCEDURE），存储过程里可以显式 COMMIT。

sql复制CREATE OR REPLACE PROCEDURE cleanup_events()
LANGUAGE plpgsql
AS $$
DECLARE
    batch_size int := 5000;
    deleted_count int;
BEGIN
    LOOP
        DELETE FROM events
        WHERE id IN (
            SELECT id
            FROM events
            WHERE created_at < now() - interval '30 days'
            ORDER BY id
            LIMIT batch_size
        );
        GET DIAGNOSTICS deleted_count = ROW_COUNT;
        COMMIT;
        EXIT WHEN deleted_count < batch_size;
        PERFORM pg_sleep(0.1);
    END LOOP;
END $$;

CALL cleanup_events();

这样每次删除 5000 行后立即提交，事务短，锁持有时间短，WAL 也能及时被 checkpoint 刷出，对整个集群的影响会平滑很多。

4.2 批次大小怎么定?

批次大小并没有一个万能数值，它取决于表的行宽、磁盘 IO、复制延迟容忍度等多个因素。我用过的经验范围是 1000 到 20000 行。行宽小的表可以批次大一点，行宽大、包含 text/jsonb 字段的表，一次删 1000 行都可能产生比较大的 IO。

判断批次是否合适的最直接指标是单次 DELETE 的执行耗时。假设目标是大批次删除持续运行，单次耗时最好控制在 1 秒以内，如果耗时超过 2~3 秒，说明批次太大或者索引效率不高。其次是观察复制延迟。如果集群有从库，在分批删除期间不断查询 pg_stat_replication，看到 replay_lag 在持续增长，就应该调小批次并增加 pg_sleep 间隔。

批次设计还有一个细节：用主键范围分段删除通常优于使用 LIMIT 子查询删除。常见做法是先取需要清理的数据的主键最大最小值，然后切成 N 段，逐段 DELETE。比如：

sql复制-- 找出目标范围内主键的边界
SELECT min(id), max(id)
FROM events
WHERE created_at < now() - interval '30 days';

拿到边界后，按主键区间循环删除。这种方式的优点是利用主键索引进行范围扫描，每批删除都落在有序区间内，对索引页的访问更集中，也比随机挑选要删除的行更平滑。

4.3 后台参数与 WAL 防止写放大

大批量 DELETE 期间的 PostgreSQL 参数调整，常常被忽略，但影响很大。核心思路是不要让它产生大量 WAL 堆积，也不要频繁触发 checkpoint。

可以临时把归档和复制的相关策略适当放宽，比如：

sql复制ALTER SYSTEM SET max_wal_size = '8GB';
ALTER SYSTEM SET checkpoint_timeout = '15min';
SELECT pg_reload_conf();

注意这些参数不是无脑调大，而是要让 checkpoint 频率降下来，避免删除过程中反复做全量检查点，造成 IO 抖动。等清理任务结束，要记得恢复原值。

另一个常被忽视的是 autovacuum 的工作机制。大批量删除后，表的 pg_stat_user_tables.n_dead_tup 会暴涨。如果 autovacuum 的触发阈值默认是 20% 的行数变化，它可能在大表删除到一半时就自动跑起来，和你的 DELETE 抢 IO。这时可以临时用以下方式让某个表跳过自动 vacuum：

sql复制ALTER TABLE events SET (autovacuum_enabled = false);
-- 清理任务结束后再开启并手动 vacuum
ALTER TABLE events SET (autovacuum_enabled = true);
VACUUM (ANALYZE) events;

但要注意：关闭 autovacuum 期间如果数据库发生崩溃，未清理的 dead tuple 会加重恢复开销，所以这个操作只适合维护窗口期，不能长期关闭。

4.4 针对亿级表的回归清理方案

我处理过一个接近 5 亿行的历史流水表，它的清理任务原本是每天一条 DELETE 删除过期数据，后来撑不住了。最终方案是把它改造成按月份的分区表，旧数据月度拆分，清理动作从"DELETE 一个月前数据"变成"DROP 三个月前的分区"，夜间任务从几十分钟缩短到秒级。

如果你的表已经很大，改造期间还残留有一大批历史数据需要清理，可以这样做：先按时间范围分批把老数据迁移到一个独立的归档表，确认业务无感后，用 TRUNCATE 清空主表，再重建索引，最后把保留数据重新导入。这套办法比直接 DELETE 几亿行安全得多，因为 TRUNCATE 不产生大量 dead tuple，而且后续索引重建可以让数据页更紧凑。

迁移的具体语言可以用 pg_dump 加 --inserts，或者直接用 SQL 按时间窗口 INSERT INTO ... SELECT。如果业务不允许长时间锁表，最佳方案是采用分区表 + 定期 DROP 分区组合，这也是目前 PostgreSQL 社区处理时间序列历史数据的标准做法。

5. 那些让 DELETE 变慢却查不动的原因：外键与锁

5.1 外键约束会触发全表扫描校验

这是 DELETE 操作里最隐蔽的性能陷阱。假设有父表和子表：

sql复制CREATE TABLE customers (
    id bigint PRIMARY KEY,
    status text
);

CREATE TABLE orders (
    id bigint PRIMARY KEY,
    customer_id bigint REFERENCES customers(id)
);

CREATE INDEX idx_orders_customer_id ON orders(customer_id);

当你 DELETE customers 里的一行时，PostgreSQL 必须检查 orders 表里是否还有引用该 customer 的订单，以保证外键约束不被破坏。如果 orders.customer_id 上没有索引，检查过程就不得不扫描整个 orders 表。即使你的本意只是删一个无效客户，PostgreSQL 也可能会把几千万行的订单表扫一遍，任何一条 DELETE 都慢得像全表操作。

更麻烦的是，如果子表的数据量巨大，而且有很多并发事务都在往子表里插入和删除，外键检查时拿到的快照和锁会产生额外的争用。生产环境遇到过一种场景：删除父表某行时，子表正有大批量 INSERT 在跑，两边互相等待，最后表现为 DELETE 卡死。

解决办法是三条路径：一是确保外键列上有索引，这是最刚性的要求；二是评估外键约束是否必要，如果允许短时间的不一致且业务能兜底，考虑删除外键改为应用层校验；三是删除父表数据时，先清理子表引用，再删除父表记录，让外键检查变成空操作。

5.2 触发器带来的二次查询风暴

触发器是另一个会让 DELETE 从"简单标记"变成"级联风暴"的元凶。比如你在 orders 表上建了一个 AFTER DELETE 触发器，每次删除订单后要去更新 customers 表的订单计数：

sql复制CREATE OR REPLACE FUNCTION after_delete_order()
RETURNS trigger AS $$
BEGIN
    UPDATE customers
    SET order_count = order_count - 1
    WHERE id = OLD.customer_id;
    RETURN OLD;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER trg_after_delete_order
AFTER DELETE ON orders
FOR EACH ROW EXECUTE FUNCTION after_delete_order();

单条删除时没问题，可当你执行 DELETE FROM orders WHERE created_at < ... 删掉十万行时，这个触发器就会被执行十万次，每次还要去更新 customers 表，代价成倍放大。用一条 DELETE 能解决的事情，因为触发器存在，实际执行的成本可能比 UPDATE 一整张表还高。

排查方法是在 pg_trigger 里查看表上是否存在 FOR EACH ROW 触发器。如果确认只需要在批量维护时执行删除，可以在维护窗口临时禁用触发器：

sql复制ALTER TABLE orders DISABLE TRIGGER trg_after_delete_order;
-- 执行批量 DELETE
ALTER TABLE orders ENABLE TRIGGER trg_after_delete_order;

但这会让触发器维护的统计信息失真，所以禁用前要评估业务可接受度，不能贸然使用。

5.3 锁等待的排查 SQL

当你发现 DELETE 一直不返回时，常见的原因不是锁就是慢查询，但需要快速判断。PostgreSQL 提供了锁等待视图，最常用的定位 SQL 是：

sql复制SELECT
    blocked.pid AS blocked_pid,
    blocking.pid AS blocking_pid,
    blocked.query AS blocked_query,
    blocking.query AS blocking_query,
    blocked.wait_event_type,
    blocked.wait_event
FROM pg_stat_activity blocked
JOIN pg_stat_activity blocking
  ON blocking.pid = ANY(pg_blocking_pids(blocked.pid))
WHERE blocked.query ILIKE 'DELETE%';

看到 blocking_pid 对应的 query 后，再去判断是继续等待还是终止。如果阻塞事务确实是无用的空闲事务，可以用：

sql复制SELECT pg_terminate_backend(blocking_pid);

生产环境的锁等待陷阱里，很大比例是应用没提交事务导致的。比如应用开启了事务，执行了一条 SELECT，然后长时间不动，也没提交也没回滚，这时任何针对相关表的 DELETE 或 UPDATE 都会被它阻塞。所以在处理 DELETE 卡死之前，先看锁等待，先找到"谁拿着锁不放"。

6. 删除完不等于结束：空间、膨胀与 VACUUM

6.1 dead tuple 与可见性:为什么表空间不缩小

很多人执行完 DELETE 后，发现表占用的磁盘空间一点都没有减少，甚至比之前还大，于是怀疑数据库出了问题。原因是：PostgreSQL 的 DELETE 只标记 dead tuple，真正的空间回收依赖 VACUUM。VACUUM 会把 dead tuple 占用的空页标记为可复用，后续插入新数据时优先填充这些空页，但文件本身不会被自动裁剪缩小。

这种"空间不归还操作系统"的机制是 PostgreSQL 的常规行为，目的是减少频繁扩展文件的成本。问题在于，如果一张表执行了大批量 DELETE，清理后的空白空间如果远远大于实际剩余数据，即使 autovacuum 正常执行了，表的物理文件依然很大。后续查询和索引扫描要遍历这些空页，性能会明显下降。

要想让空间真正归还给文件系统，需要执行 VACUUM FULL。它相当于重建表，把有效数据重新排列到一个全新的文件里，空闲空间不再保留。VACUUM FULL 会获取 ACCESS EXCLUSIVE 锁，阻塞读写，所以只能放在维护窗口执行。

sql复制VACUUM (FULL, ANALYZE) events;

6.2 如何量化表膨胀

判断表是否已经膨胀到需要处理的程度，不能靠感觉。可以通过 pg_stat_user_tables 里 n_live_tup 和 n_dead_tup 粗略判断：

sql复制SELECT
    relname,
    n_live_tup,
    n_dead_tup,
    CASE WHEN n_live_tup > 0
         THEN round(n_dead_tup * 100.0 / n_live_tup, 2)
         ELSE 0 END AS dead_pct
FROM pg_stat_user_tables
WHERE relname = 'events';

如果 dead_pct 长期超过 20%，说明 VACUUM 清理速度跟不上产生速度，要么 autovacuum 不够积极，要么确实产生大量删除。另一种更准确的办法是使用第三方扩展 pgstattuple：

sql复制CREATE EXTENSION IF NOT EXISTS pgstattuple;
SELECT * FROM pgstattuple('events');

它可以直接返回表的 dead tuple 数量和 free space 占比。如果 free_percent 超过 50%，说明表文件里空页太多，即使有效数据不多，物理读取成本也高。这种表就该排个维护窗口跑 VACUUM FULL 或 pg_repack。

6.3 autovacuum 设置与手动维护节奏

PostgreSQL 默认的 autovacuum 设置偏保守，对经常执行 DELETE 的表可以做单独调优。最重要的参数是 autovacuum_vacuum_scale_factor，默认 0.2，意思是当 dead tuple 数超过表行数的 20% 时才触发。你可以通过表的存储参数单独覆盖：

sql复制ALTER TABLE events SET (autovacuum_vacuum_threshold = 1000);
ALTER TABLE events SET (autovacuum_vacuum_scale_factor = 0.05);
ALTER TABLE events SET (autovacuum_analyze_threshold = 500);
ALTER TABLE events SET (autovacuum_vacuum_cost_delay = 5);

这样一来，表里只要积累超过 5% 的 dead tuple 就会触发 autovacuum，清理滞后性大大降低。阈值不宜设太低，否则高频率的 DELETE 会让 autovacuum 几乎不停运行，反而消耗 IO。

手动维护的节奏方面，我一般这样把握：大批量删除任务执行完以后，先观察 n_dead_tup 和 pg_stat_activity 中 autovacuum 是否已经开始，如果 10 分钟内没有启动，或任务留有维护窗口，就直接手动执行：

sql复制VACUUM (ANALYZE) events;

平时不主动跑 VACUUM FULL，除非表膨胀严重或大量空间需要释放。还可以周期性用 pg_repack 替代 VACUUM FULL 来做在线整理，它不阻塞读写，但部署和操作成本更高，适合表比较大又不能停业务的场景。

最后再分享一个经验：很多人把 DELETE 用不好，不是不会写 SQL，而是忽略了它作为"事务写入+异步清理"的复合身份。每次写完大批量 DELETE，我都会额外问自己三个问题——它会产生多少 WAL？它什么时候释放锁？它生成的 dead tuple 谁来清？把这三个问题想清楚，DELETE 才不会成为线上事故的导火索。