阿里面试：千万级大表如何快速删除大量数据
1. 一次性直接删除大量数据的风险
1.1 锁表导致业务阻塞
- 问题：大事务删除会长时间锁表，阻塞其他查询/写入操作。
案例：删除1000万条数据耗时2小时，期间用户无法下单或查询。 - 后果：业务接口超时、页面卡顿，用户体验下降。
1.2 事务日志爆炸
- 问题：数据库记录全量删除日志（用于回滚），日志体积激增。
案例：删除1亿条数据，日志可能增长500GB，撑满磁盘。 - 后果：磁盘空间不足，数据库崩溃。
1.3 CPU飙升与性能下跌
- 问题：删除时需更新索引、触发约束检查，大量占用CPU和I/O资源。
案例：删除期间CPU使用率达100%，正常查询延迟从2ms升至10秒。
1.4 主从延迟
- 问题：主库大事务同步到从库耗时久，导致主从数据不一致。
案例：主库删除耗时2小时，从库延迟3小时，报表数据错误。
1.5 回滚困难
- 问题：删除中途失败时，回滚耗时可能比删除更久，甚至导致数据损坏。
案例：删除5000万条数据中断后，回滚需2小时，业务停摆加剧。
2. 删除前预演
2.1 评估数据量与选择方案
- 数据量大（如删除90%以上）：优先使用 新建表+删除旧表法。
- 数据量小（如删除10%以下）：采用 分批删除 更高效。
2.2 优化删除条件索引
- 确保删除条件字段（如日期、ID范围）已创建索引，加速数据定位。
- 注意：避免索引在删除过程中产生额外负担。
2.3 数据备份
- 全量备份：删除前对表进行完整备份。
- 增量备份：分批删除时，定期做增量备份以降低数据丢失风险。
3. 大批量数据删除方案
3.1 分批删除（核心方案）
- 原理：将大事务拆分为小批次，避免锁表和日志膨胀。
-- 每次删除1000条，循环执行
DELETE FROM tianluo_tab WHERE 条件 LIMIT 1000; - 优化点：
- 关闭自动提交：
SET autocommit=0;，手动控制事务提交频率。 - 批次间添加短暂停顿（如0.1秒），避免瞬间压力过大。
3.2 分区表删除（需提前设计）
- 适用场景：数据按时间/范围分区（如日志表）。
-- 直接删除整个分区（秒级完成）
ALTER TABLE table DROP PARTITION partition_name; - 优点：无需逐行删除，直接清理物理文件，效率极高。
3.3 新建表替换旧表（删除大量数据）
- 步骤：
- 建新表：仅插入需保留的数据。
sql CREATE TABLE new_table AS SELECT * FROM old_table WHERE 保留条件; - 重命名表：快速切换新旧表。
sql RENAME TABLE old_table TO old_table_backup, new_table TO old_table; - 删除旧表：确认数据无误后删除备份表。
sql DROP TABLE old_table_backup;
- 优点：几乎不锁表，速度快；缺点：需重建索引、外键。
3.4 TRUNCATE清空表（删除全量数据）
- 适用场景：需删除表中所有数据，保留表结构。
TRUNCATE TABLE tianluo_tab; -- 比DELETE更高效，直接释放空间 3.5 辅助技巧与工具
- 工具推荐：MySQL可使用
pt-archiver自动分批删除，降低对业务的影响。 - 操作时机：选择业务低峰期执行，减少资源竞争。
- 备库测试：先在从库模拟删除操作，验证方案可行性。
- 冷数据迁移：将旧数据迁移至归档表后再删除，减轻主表压力。
4. 删除后后置处理
4.1 数据验证
- 验证删除范围：
SELECT COUNT(*) FROM tianluo_tab WHERE 已删除条件; -- 结果应为0 - 验证数据完整性：随机抽查未删除数据，确保无遗漏或误删。
- 关联系统验证：检查依赖该表的业务功能（如报表、API）是否正常。
4.2 监控与日志记录
- 性能监控：观察CPU、内存、I/O是否恢复正常，检查慢查询日志。
- 操作记录：记录删除时间、数据量、操作人，便于审计追溯。
4.3 资源释放
- 回收磁盘空间：
-- MySQL（InnoDB）
OPTIMIZE TABLE tianluo_tab; -- 重建表释放空间（注意锁表风险）
-- PostgreSQL
VACUUM FULL tianluo_tab; 总结
处理千万级大表删除时，核心原则是：
- 避免大事务：采用分批、分区等方案拆解操作。
- 提前规划：利用索引、分区表等设计降低删除成本。
- 风险控制：充分备份、测试，选择低峰期执行。
合理选择方案并做好全流程监控，可大幅降低删除操作对系统的影响。