DROP DATABASE会直接、不可逆地删除整个数据库及其所有对象，不进回收站且无法通过binlog自动回滚，生产环境必须确认权限与备份后方可执行。
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 missing - binlog 记录不完整，主从同步断裂
- 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、慢日志、应用配置、运维文档，比敲一条命令花的时间多得多。
