必须先确认当前连接和目标库名，SELECT DATABASE()返回NULL才安全；别信客户端界面显示，用SHOW DATABASES LIKE 'target_name'校验；DROP DATABASE IF EXISTS不防误删，仅防报错；删库前须完整备份并清理权限与复制链路。
确认当前连接和目标库名，别信界面显示
执行 DROP DATABASE 前，SELECT DATABASE() 返回 NULL 才算安全——如果它返回了你要删的库名，说明你正连在里头，一删就断连，客户端可能卡住或报 Lost connection to MySQL server during query。别依赖 MySQL Workbench 或 Navicat 标题栏写的“当前库”，那是 UI 缓存，不一定等于实际上下文。
用 SHOW DATABASES LIKE 'target_name' 查一遍，比靠记忆或配置文件更可靠。开发/测试/生产环境常共用前缀（如 app_dev/app_prod），输错一个字母就删错实例。
完整连接串必须显式指定：mysql -h 10.0.1.5 -P 3307 -u admin -p -e "DROP DATABASE risky_db"，省略 -h 或 -P 容易连错本地默认实例。
加 IF EXISTS 不代表安全，只是不报错
DROP DATABASE IF EXISTS wrong_name 不会报错，但也没删成——它掩盖了拼写错误，反而让你误以为操作成功。脚本中用 IF EXISTS 是为了防中断，不是防误删。
真正需要的是前置校验逻辑，比如：
if mysql -Nse "SELECT SCHEMA_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = 'target_db'" | grep -q target_db; then echo "✅ 库存在，继续" else echo "❌ 库不存在，退出" exit 1 fi
否则，IF EXISTS 在批量清理临时库时有用，但对关键库毫无保护作用。
删库前必须导出备份，且注意 --single-transaction 限制
mysqldump -u root -p --single-transaction target_db > backup.sql 是最低要求，但要注意：--single-transaction 对 MyISAM 表无效，会锁表；如果库混用引擎，得改用 --lock-all-tables 或停写。
备份后别只存本地磁盘——backup.sql 文件要立即 scp 到另一台机器，或上传到对象存储。曾经有案例：删库 + 本地 SSD 故障 + 备份文件损坏，三重失效。
导出时加 --routines --triggers --events，否则存储过程、触发器这些不会进备份。
删完不是结束，权限和复制链路还在漏
DROP DATABASE 不动 mysql.db 表，残留的 GRANT ... ON target_db.* 记录仍可查到，但已无效。得手动清理：REVOKE ALL PRIVILEGES ON target_db.* FROM 'user'@'host';，再 DROP USER（如果该账号只为此库服务）。
主从环境下，删库语句会原样写入 binlog 并在从库重放——哪怕从库上该库正被其他业务跨库查询，也会被一起删掉。没有“跳过不存在库”的机制，IF EXISTS 在从库重放时也不起作用。
删大库时，SHOW PROCESSLIST 会看到状态是 deleting 或 dropping table，这时千万别 KILL 线程，可能卡死 InnoDB 文件系统层。
最常被忽略的点：删库本身很快，但后续权限回收、从库验证、应用配置下线、监控告警规则清理，这些步骤没做完，等于只拆了门没拆地基。
