批量删除大量数据性能差主因是索引与事务管理不当：删前停用非必要索引，删时分批+短事务控制，优先用TRUNCATE清空整表或分区，删后及时更新统计信息并重建索引。
批量删除大量数据时，性能差往往不是因为SQL写得不对，而是没管好索引和事务机制。核心思路是：删之前先评估索引影响，删的时候控制事务粒度，删完及时释放资源。
删前停用非必要索引
DELETE操作会触发所有相关索引的同步更新，尤其是高基数、多列组合索引或全文索引，开销极大。对目标表中不用于WHERE条件、也不参与后续JOIN/ORDER BY的索引，可临时禁用（MySQL用ALTER TABLE ... DISABLE KEYS，PostgreSQL需DROP INDEX CONCURRENTLY后重建）。
- 只禁用辅助索引，主键/唯一约束索引不可禁用
- 禁用后执行删除，完成后立即重建（避免长时间无索引状态）
- 在低峰期操作，并提前备份元数据结构
分批删除 + 显式事务控制
一次性DELETE千万级记录极易锁表、占满undo日志、触发OOM。应按主键或时间字段切片，每次处理5k–50k行，配合短事务提交。
- 用WHERE限定范围，例如WHERE id BETWEEN ? AND ? 或 WHERE create_time < '2022-01-01'
- 每批用独立事务包裹，避免长事务阻塞其他写入
- 两次删除间加毫秒级休眠（如pg_sleep(0.1)），缓解IO压力
用TRUNCATE替代DELETE（当适用时）
如果要清空整表或按分区删除，且不需要触发器、不依赖事务回滚、无外键引用，TRUNCATE比DELETE快一个数量级——它不逐行标记，不写redo日志，直接重置存储指针。
- TRUNCATE无法带WHERE，也不能在有外键依赖的表上直接执行
- 某些数据库（如MySQL InnoDB）支持TRUNCATE分区：ALTER TABLE t TRUNCATE PARTITION p1
- 执行后自增ID重置，注意应用层是否依赖连续ID
删后更新统计信息与重建索引
大批量删除会导致索引页稀疏、数据分布失真，优化器可能选错执行计划。删除完成后应主动刷新统计：
- MySQL：运行ANALYZE TABLE t
- PostgreSQL：运行ANALYZE t 或 VACUUM ANALYZE t
- 若删除比例超30%，考虑重建主键索引（REINDEX INDEX idx_name 或 OPTIMIZE TABLE）
