优先用truncate table清空大表，因其直接释放数据页、重置auto_increment、不写undo log、不触发trigger；但需满足无外键引用、无需回滚、无触发器依赖且有drop权限，否则须改用分批delete from。
直接说结论：对大表清空数据，优先用 TRUNCATE TABLE，但必须确认表没被外键引用、不需要回滚、不依赖触发器——否则只能退到 DELETE FROM 加分批处理。
为什么不能直接用 DELETE FROM table_name 清空大表
执行 DELETE FROM 时，MySQL 是逐行扫描 + 逐行标记删除 + 写入 undo log 和 binlog。表越大，耗时越长、锁表时间越久、事务日志膨胀越严重。
- 在 InnoDB 中，
DELETE不释放磁盘空间（只是逻辑删除），后续INSERT可复用空闲页，但表文件大小不变 - 若未显式开启事务，
DELETE仍会隐式启动自动提交事务，一旦中途失败（如超时、OOM），可能残留部分已删、部分未删的中间状态 - 如果表上有
ON DELETE触发器，DELETE会逐行触发，进一步拖慢速度并增加不确定性 - 执行
DELETE FROM t后，AUTO_INCREMENT值不会重置，新插入记录 ID 会接着上次最大值继续，容易造成 ID 稀疏或溢出风险
TRUNCATE TABLE 快在哪？又有哪些硬限制
TRUNCATE TABLE 本质是“重建空表”：它先删掉原表的数据段（data pages），再新建一个空段，跳过所有行级操作和日志记录。所以快，但也因此牺牲了灵活性。
- 不写 undo log，不可回滚；不写 binlog 的 row 格式事件（只记 DDL 语句），无法用 binlog 回放恢复
- 不触发任何
DELETE或BEFORE/AFTER触发器 - 要求用户有
DROP权限（不是DELETE权限），很多生产环境账号默认不给 - 不能用于有外键约束被引用的表（MySQL 会报错
Cannot truncate a table referenced in a foreign key constraint） - 执行后
AUTO_INCREMENT重置为 1（InnoDB 和 MyISAM 均如此）
大表清空前必须检查的 4 件事
别急着敲命令，先验证这几点，否则可能锁库数小时或直接中断业务：
- 查外键依赖：
SELECT CONSTRAINT_NAME, TABLE_NAME, COLUMN_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'your_table'; - 确认无活跃事务占用该表：
SELECT * FROM information_schema.INNODB_TRX WHERE trx_mysql_thread_id IN (SELECT ID FROM information_schema.PROCESSLIST WHERE INFO LIKE '%your_table%'); - 检查是否启用了
sql_log_bin=0（禁用 binlog）—— 若需主从同步，不能关；若关了，TRUNCATE将不会同步到从库 - 确认备份已完成：
mysqldump --single-transaction -t your_db your_table > backup_your_table.sql（-t表示只导数据）
实在不能用 TRUNCATE 时，DELETE 怎么安全分批删
当表被外键引用、需要触发器、或权限受限时，DELETE 是唯一选择。但必须避免全表扫一次就锁死：
- 按主键范围分片删，例如：
DELETE FROM t WHERE id BETWEEN 1 AND 10000;，循环递增 until 没有更多行 - 每次删完加
SLEEP(0.1)（用应用层控制），避免 I/O 和 CPU 打满 - 监控
SHOW PROCESSLIST和information_schema.INNODB_METRICS中的dml_deletes计数 - 删完立刻执行
OPTIMIZE TABLE t;（仅 MyISAM 必须；InnoDB 可选，但能真正释放空间并重建聚簇索引）
真正危险的不是命令本身，而是没看清楚表是否被其他模块强依赖、没确认 binlog 格式、没预留足够磁盘空间存临时日志——这些地方一漏，TRUNCATE 会秒删，DELETE 会卡死，恢复起来比删之前还费劲。
