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 中它是隐式提交） - 若需条件清空（如只删 2023 年前数据），必须用
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。