地理空间表的delete操作无法批量跳删，需结合空间索引优化、分批处理、ctas重建或vacuum/optimize清理。
DELETE 语句本身不支持地理空间条件的批量优化
SQL 标准的 DELETE 无法跳过索引扫描或利用空间索引做“批量跳删”，哪怕表上有 GEOMETRY 列并建了 GIST（PostGIS）或 SPATIAL（MySQL）索引。执行 DELETE FROM tbl WHERE ST_Within(geom, some_polygon) 仍会逐行评估谓词，只是空间索引能加速 ST_Within 的内部包围盒预筛选。
常见错误现象：DELETE 卡住、事务膨胀、WAL 日志暴涨、触发器被反复调用——尤其当匹配行数超 10 万时。
- 务必在执行前用
EXPLAIN ANALYZE看是否命中空间索引（关注是否出现Index Scan using xxx_gist on tbl） - 避免在
WHERE中写ST_Transform(geom, 4326) && some_box：强制转换会失掉索引；应确保查询坐标系与索引一致 - PostgreSQL 中，若表有
AFTER DELETE触发器，每删一行都触发一次——批量删前先DISABLE TRIGGER，删完再ENABLE
用 CTAS + RENAME 替代大范围 DELETE（PostgreSQL / Greenplum）
当要删除 >30% 的行，物理重建表比原地删除更高效，还能自然清理 bloat 和释放空间。关键是保留原表结构（含约束、索引、权限），不能只靠 CREATE TABLE AS。
实操步骤：
- 用
pg_get_serial_sequence('tbl', 'id')查原表主键序列名，后续需重置 - 新建临时表：
CREATE TABLE tbl_new (LIKE tbl INCLUDING ALL) WITH (autovacuum_enabled = false); - 插入保留数据：
INSERT INTO tbl_new SELECT * FROM tbl WHERE NOT ST_Within(geom, drop_area); - 切换：
BEGIN; DROP TABLE tbl; ALTER TABLE tbl_new RENAME TO tbl; RESET OWNED BY CURRENT_ROLE; COMMIT; - 手动重建序列：
SELECT setval('tbl_id_seq', (SELECT MAX(id) FROM tbl));
注意：INCLUDING ALL 包含默认值、约束但不含外键依赖；若有外键指向该表，需先 ALTER TABLE ref_table DROP CONSTRAINT，切换后再加回。
分批 DELETE 防锁表和 OOM（所有数据库通用）
不分批的 DELETE 会让整个表长时间持 ROW EXCLUSIVE 锁，阻塞读写；而单次删太多行又可能撑爆事务内存。核心是控制每次最多删 5k–10k 行，并用主键/空间索引字段驱动游标。
PostGIS 示例（安全分批）：
DO $$
DECLARE
r RECORD;
BEGIN
FOR r IN
SELECT ctid FROM my_points
WHERE geom && ST_MakeEnvelope(-180,-90,180,90,4326)
ORDER BY ctid
LIMIT 10000
LOOP
DELETE FROM my_points WHERE ctid = r.ctid;
COMMIT; -- 每批独立事务
PERFORM pg_sleep(0.01); -- 防止锁竞争
END LOOP;
END $$;
关键点：
- 用
ctid或带索引的整型主键（如id）分页，别用OFFSET/LIMIT：后者越往后越慢 - 每次
COMMIT后必须pg_sleep或等 WAL 刷盘完成，否则复制延迟飙升 - MySQL 用户请改用
WHERE id BETWEEN ? AND ?+ORDER BY id，且确保id是聚簇索引
DELETE 后必须手动 VACUUM（PostgreSQL）或 OPTIMIZE TABLE（MySQL）
即使删完，空间不会自动还给操作系统。PostgreSQL 不会自动回收 dead tuple 占用的页，MySQL 的 InnoDB 也不会立即收缩 .ibd 文件。
忽略这步的后果：
- 表体积不变，后续 INSERT 仍写入旧空闲页，导致空间碎片化
-
VACUUM FULL会锁表，生产环境慎用；优先选VACUUM (PARALLEL 4) tbl - MySQL 8.0+ 可对
SPATIAL索引表执行OPTIMIZE TABLE tbl，但会重建整表——等同于 CTAS 方案，只是由引擎自动做 - PostGIS 用户额外检查：
SELECT postgis_full_version();若低于 3.2，ST_ClusterDBScan等函数在 vacuum 后可能失效，需ANALYZE tbl
地理空间表的 delete 不是纯逻辑操作，它牵扯索引结构、磁盘布局、甚至投影元数据缓存。最常被跳过的其实是 vacuum 和统计信息更新——删完看行数对了就以为结束了，但下一次空间查询可能慢 3 倍。
