不能直接DELETE全表，因会引发长锁、日志爆满、同步延迟、事务失败及索引分裂；应分批按主键范围删除，如WHERE id > 100000 AND id
直接用DELETE FROM table删几百万行？风险高、锁表久、日志爆满、业务卡死——这不是删除，是“自毁式操作”。安全高效删大量数据，核心就三点：分批删、避全表锁、控事务大小。
为什么不能直接 DELETE 全表？
MySQL/PostgreSQL 中，单条 DELETE 若影响行数过多，会：
• 持有长时间行锁或表级锁，阻塞读写
• 生成巨量 undo/redo 日志，拖慢主从同步甚至填满磁盘
• 触发自动提交失败或超时中断，留下不一致状态
• 在 InnoDB 中还可能引发索引分裂、缓冲池压力飙升
推荐方案：分批次 + 主键范围删除
以 MySQL 为例，假设要删 orders 表中 created_at 的旧数据（共 500 万行）：
-
先加索引：确保
created_at或组合条件字段有高效索引（如(created_at, id)） -
按主键切片删：避免 OFFSET 跳跃，用
WHERE id BETWEEN x AND y AND created_at 安全推进 - 每次删 5000～10000 行：控制事务体积，减少锁持有时间（示例）：
SELECT MIN(id), MAX(id) FROM orders WHERE created_at
-- 分批执行（每次取 1w 行，带 sleep 防冲击）
DELETE FROM orders WHERE id >= 100000 AND id
-- 删除后可加 SELECT ROW_COUNT() 确认实际删了多少更优场景：用 TRUNCATE 或 DROP PARTITION
如果满足以下任一条件，优先选它们：
-
删整张表数据 → 用
TRUNCATE TABLE orders：不走事务、不记完整日志、秒级完成（但不可回滚，且重置 AUTO_INCREMENT）
-
表按时间分区（如 RANGE 分区） → 直接
ALTER TABLE orders DROP PARTITION p_2021;：物理删除，无日志压力，毫秒级
-
需要保留表结构+少量数据 → 先 CREATE TABLE AS SELECT 保留有效数据，再 RENAME 切换，最后 DROP 旧表（适合离线维护窗口）
必须做的安全收尾动作
删完不是结束：
-
立刻 ANALYZE TABLE orders：更新统计信息，避免后续查询走错执行计划
-
检查碎片率：InnoDB 可查
information_schema.INNODB_SYS_TABLES 的 DATA_FREE，偏高则考虑 OPTIMIZE TABLE（注意该操作会锁表）
-
核对数据量与业务逻辑：用
COUNT(*) 抽样验证，比对归档日志或 binlog 位点，确认没误删
-
清理相关索引/外键依赖：比如删了主表旧数据，关联的子表历史记录是否也要清理？别漏掉级联死角
