17370845950

DROP TABLE 是最危险的 DDL 操作，应先重命名隔离观察 3–7 天确认无依赖再删除；清空表优先用 TRUNCATE；大表删数据须分批；跨库外键需手动排查。

用 DROP TABLE 删除表前，先重命名“隔离”再观察

直接 DROP TABLE 是线上最危险的 DDL 操作之一——它瞬间删掉结构+数据+索引，且无法回滚。一旦有隐藏依赖（比如定时任务里硬编码了表名、某个存储过程没被发现），服务立刻报错 Table 'xxx' doesn't exist。

• 正确做法是先 ALTER TABLE t1 RENAME TO t1_bak_20251229，切断所有直连访问
• 观察 3–7 天：查应用日志、SHOW PROCESSLIST 看是否有残留连接、检查慢日志里是否还出现原表名
• 确认无依赖后，再执行 DROP TABLE t1_bak_20251229
• 万一发现误操作？1 秒回滚：ALTER TABLE t1_bak_20251229 RENAME TO t1

清空整张表时，别用 DELETE FROM，优先选 TRUNCATE TABLE

DELETE FROM t1 看似干净，实则埋雷：它逐行删除、写 binlog（主从延迟暴增）、不释放磁盘空间（InnoDB 表空间文件不缩容），且自增 ID 不重置。

• TRUNCATE TABLE t1 是原子操作：重建表结构、清空数据、重置自增、释放空间、不记完整 binlog（只记 DDL 日志）
• 但注意：TRUNCATE 不能带 WHERE，也不能在事务中回滚（MySQL 中它是隐式提交）
• 若需条件清空（如只删 2025 年前数据），必须用 DELETE ... WHERE，但务必加索引 + 分批（见下一条）

大表删数据必须分批，否则锁表+OOM+主从断裂

对千万级表执行 DELETE FROM logs WHERE created_at ，可能卡住 20 分钟，期间阻塞所有写入，binlog 堆积，从库延迟飙升到小时级。

• 用主键范围分批删：

  DELETE FROM logs WHERE id <= 1000000 AND created_at < '2023-01-01' LIMIT 10000;

• 每次删完查下 SELECT ROW_COUNT()，为 0 则停止；否则休眠 0.1s 再继续（避免打满 IO）
• 生产环境建议用 pt-archiver 工具替代手写脚本，它自动处理锁、延迟、校验

删数据库前，三件事缺一不可：查连接、关应用、导备份

DROP DATABASE 是终极删除，没有“回收站”，也没有“确认弹窗”。MySQL 不会管你有没有正在跑的微服务在连这个库。

• 先查活跃连接：SELECT * FROM information_schema.PROCESSLIST WHERE DB = 'target_db';，有结果就 kill 掉
• 确认无外部依赖：检查应用配置文件、K8s ConfigMap、CI/CD 脚本、监控告警规则里是否引用该库名
• 备份不是可选项：mysqldump -u root -p --single-transaction target_db > target_db_$(date +%Y%m%d).sql，哪怕只是留个 schema

真正容易被忽略的是：外键跨库引用。如果其他库的表通过外键指向你要删的库，DROP DATABASE 会失败，但错误信息只显示 ERROR 1216 (HY000)，不提示具体哪张表在依赖——得手动查 information_schema.KEY_COLUMN_USAGE。