drop database 会直接删除整个数据库，不可逆
MySQL 的
DROP DATABASE是高危操作，执行后所有表、视图、存储过程、权限配置等全部消失，且不进回收站、无法通过 binlog 自动回滚（除非你提前启用了 Flashback 工具或有备份）。生产环境严禁在没有确认和备份的情况下运行。 必须拥有
DROP权限（通常需
CREATE+
DROP） 数据库名区分大小写，取决于系统变量
lower_case_table_names设置 如果数据库不存在，默认报错
ERROR 1008 (HY000): Can't drop database 'xxx'; database doesn't exist加
IF EXISTS可静默跳过不存在的库，避免脚本中断：
DROP DATABASE IF EXISTS mydb;
删除前务必确认当前数据库和连接用户权限
误删常发生在切换数据库后没注意上下文。用
SELECT DATABASE();查当前库；用
SELECT USER();确认身份；再用
SHOW GRANTS FOR CURRENT_USER;检查是否真有
DROP权限——有些账号被限制只能删指定前缀的库（如只允许删
tmp_开头的）。 别依赖客户端界面显示的“当前库”，它可能缓存或误导（比如 MySQL Workbench 标题栏显示的库名不一定等于
USE实际生效的库）
mysql -u user -p -D targetdb连接时加了
-D参数，不代表后续
DROP DATABASE就一定作用于该库——它只是默认进入，
DROP后面必须显式写库名 若用 root 或高权限账号连入，更要谨慎：权限越大，误操作代价越高
drop database 和 rm data 目录的区别在哪
DROP DATABASE是 SQL 层操作，由 MySQL Server 控制流程：先删元数据（
mysql.db、
mysql.tables_priv等），再删对应目录下的文件（.frm/.ibd/.MYD 等），最后刷新内存缓存。而手动
rm -rf /var/lib/mysql/mydb是绕过 Server 的底层删除，会导致： InnoDB 表空间 ID 不一致，重启后可能报
Tablespace is missingbinlog 记录不完整，主从同步断裂 MySQL 启动时报错，甚至拒绝启动（尤其开启
innodb_force_recovery时） 权限表残留，
SHOW DATABASES还能看到库名（因为
mysql.db没删）
所以，永远走
DROP DATABASE，不要碰文件系统。
删除大库时要注意 innodb_file_per_table 和 slow shutdown
如果库中有很多大表且
innodb_file_per_table=ON（默认），
DROP DATABASE会逐个 unlink .ibd 文件，IO 压力明显，可能卡住几秒到几分钟。此时： 监控
SHOW PROCESSLIST，状态可能是
deleting或
dropping table不要 kill 掉该线程，可能导致表空间残留或崩溃 如果 MySQL 配置了
innodb_fast_shutdown=2（默认），关闭时不会做 full purge，下次启动会慢；建议删库前设为
1或
0再重启，让清理更彻底 对于 TB 级数据库，考虑先
TRUNCATE TABLE清空单表，再
DROP DATABASE，比直接删快（但前提是业务可停）
真正难的不是语法，是判断“这个库现在到底有没有人在用”——查
information_schema.PROCESSLIST、慢日志、应用配置、运维文档，比敲一条命令花的时间多得多。
