导出与删除必须共用同一查询逻辑，避免手动复制粘贴导致漏删或报错；WHERE条件须精准，宽泛易误删；时间条件优先用STR_TO_DATE()或时间戳。
导出前必须先确认 WHERE 条件是否精准
导出陈旧数据却删错了行，90% 是因为 where 条件写宽了。比如想删 2022 年前的订单，写了 created_at ，但字段是字符串类型或时区未对齐，实际可能误删 2023 年部分数据。
- 务必用
SELECT COUNT(*)先验证范围：SELECT COUNT(*) FROM orders WHERE created_at - 检查字段类型：用
DESCRIBE orders或SHOW COLUMNS FROM orders确认created_at是DATETIME而非VARCHAR - 避免隐式转换：字符串日期比较（如
'2021-12-31' > '2022-01-01'）在某些 MySQL 版本会出错，优先用STR_TO_DATE()或统一转为时间戳
导出与删除不能靠“手动复制粘贴”串联
先 SELECT ... INTO OUTFILE 导出，再人工打开 CSV、复制 ID 列、拼 DELETE IN —— 这种操作在万级以上数据就不可靠：ID 超长截断、CSV 编码乱码、IN 子句超限（MySQL 默认 max_allowed_packet 限制），极易漏删或报错 ERROR 1305 (42000): FUNCTION xxx does not exist。
- 导出和删除应共用同一查询逻辑，例如用临时表承接：
CREATE TEMPORARY TABLE old_ids AS SELECT id FROM logs WHERE ts - 导出走
SELECT * FROM old_ids INTO OUTFILE '/tmp/old_logs.csv' - 删除走
DELETE l FROM logs l INNER JOIN old_ids o ON l.id = o.id，确保严格一对一 - 别用
mysqldump --where直接导出后删——它不保证事务一致性，导出途中若有人插入/更新，后续删的就不是原快照
DELETE 后没释放空间？别急着 OPTIMIZE TABLE
执行 DELETE FROM events WHERE created_at 后磁盘空间没变小，不是删失败，而是 InnoDB 只标记行删除，空间暂不归还给文件系统。但 <code>OPTIMIZE TABLE 会锁表、重建聚簇索引，大表可能卡住业务数小时。
- 中小表（OPTIMIZE TABLE events
- 大表或高可用要求场景：改用分批删除 +
ALTER TABLE ... ENGINE=InnoDB（仅 MySQL 5.6+ 支持在线 DDL），它比 OPTIMIZE 更轻量 - 更稳妥的做法是建新表迁移：
CREATE TABLE events_new LIKE events→INSERT INTO events_new SELECT * FROM events WHERE created_at >= '2021-01-01'→ 原子重命名切换 - 注意：如果表有外键，
ALTER TABLE ... ENGINE=InnoDB会失败，需先SET FOREIGN_KEY_CHECKS=0
自动化脚本里漏掉事务控制，等于埋雷
写 Python 脚本导出 CSV 再发 DELETE，但没包在事务里，导出成功后删除失败，数据就丢了又没备份。或者用 shell 调 mysql -e "DELETE..."，但没检查命令退出码，错误静默跳过。
- 必须用显式事务：
BEGIN; SELECT ... INTO OUTFILE ...; DELETE ...; COMMIT;（注意：INTO OUTFILE 不支持事务回滚，所以它得放在 DELETE 前且确保路径可写） - 脚本中加校验：导出后
ls -l /tmp/export.csv && wc -l /tmp/export.csv，删除后SELECT ROW_COUNT()检查影响行数是否匹配预期 - 严禁在生产环境直接跑
DELETE脚本——先在从库或影子库上完整跑通一遍流程
导出与删除联动最危险的点，从来不是语法写错，而是把“导出完成”当成“数据已安全”，却忘了验证导出内容是否完整、删除条件是否被索引覆盖、以及磁盘空间是否真被回收。
