drop database 是不可逆的物理删除操作，立即清除数据库目录及所有对象，无回收站和确认提示，会破坏主从复制并残留无效权限记录，安全删除需严格验证实例、导出备份并限制权限。
drop database 会直接删掉整个数据库，没有回收站
执行 DROP DATABASE 是不可逆操作，它会立刻删除数据库目录、所有表文件、索引、视图、存储过程等物理数据，MySQL 不提供确认提示或软删除机制。
- 如果数据库正在被连接使用（比如有活跃事务或未关闭的连接），MySQL 通常仍会执行成功，但可能引发客户端报错
Lost connection to MySQL server during query - 依赖该库的其他服务（如应用、定时任务、从库复制）会立刻失败，错误可能是
Unknown database 'xxx' - 即使只用
mysql -u root -p -e "DROP DATABASE test_db"这种命令行方式，也一样危险——没加--force也不会拦你
删除前必须确认数据库名拼写和当前环境
开发、测试、生产环境常共用相似库名（如 app_dev / app_test / app_prod），连错实例后输错一个字母就可能删错库。
- 先用
SELECT DATABASE()确认当前默认库（返回NULL表示没选库） - 再查一遍目标是否存在：
SHOW DATABASES LIKE 'target_name'，别信记忆或配置文件里的名字 - 如果通过脚本批量操作，务必在
DROP DATABASE前加判断：IF EXISTS只防报错，不防删错——DROP DATABASE IF EXISTS wrong_name不报错，但也没用
drop database 对权限和复制的影响
这个命令本身不需要 CREATE 权限，但需要 DROP 权限；真正容易被忽略的是它对复制链路的破坏性。
- 主库执行
DROP DATABASE db1后，该语句会原样写入 binlog，并在从库重放——从库上同名库也会被删掉，不会因为“从库没这个库”就跳过 - 如果从库上该库正被用于其他用途（比如跨库查询、临时同步中），删完就断了
- 用户权限里带
ON db1.*的授权记录不会自动清理，SELECT * FROM mysql.db WHERE Db='db1'还能查到残留，但已无效
安全删除的最小可行步骤
没有绝对安全的方式，只有降低误操作概率的操作习惯。
- 始终在删除前导出关键数据：
mysqldump -u root -p --single-transaction target_db > backup.sql（注意--single-transaction对非事务引擎无效） - 用完整连接串明确指定目标实例：
mysql -h 10.0.1.5 -P 3307 -u admin -p -e "DROP DATABASE risky_db"，别省略-h和-P - 生产环境禁止用 root 直接删库；应创建专用账号，仅授予待删库的
DROP权限，且该账号不能登录其他实例 - 如果只是临时停用，优先考虑
RENAME TABLE重命名所有表，或用ALTER DATABASE修改字符集/排序规则来“标记废弃”，比删库更可控
实际线上最常出问题的，不是会不会用 DROP DATABASE，而是删之前没验证连接的是哪个实例、没检查 binlog 格式是否为 ROW（STATEMENT 模式下某些情况会跳过部分对象）、以及把备份命令里的库名复制错了。
