必须用 drop database 删除数据库，否则会导致元数据残留、权限错乱、同名库重建失败；执行前须确认权限、库名拼写、连接已断开；删库后需同步清理权限并验证磁盘空间释放。
不能靠删文件夹或手动清表来“删除数据库”，必须用 DROP DATABASE，否则元数据残留、权限错乱、后续建同名库失败都是大概率事件。
执行 DROP DATABASE 前必须确认三件事
MySQL 不会二次确认，敲下回车就不可逆。常见误删源于没核对清楚：
- 当前连接的
host和user是否有足够权限？只读账号或低权限账号会报ERROR 1044 (42000): Access denied for user - 目标库名是否拼写正确？
mysql、information_schema、performance_schema这类系统库严禁删除，MySQL 8.0+ 对sys同样保护 - 是否有应用还在连这个库？没断开连接时执行
DROP DATABASE会卡住，直到所有活跃连接释放（包括长连接、未 close 的 ORM session）
DROP DATABASE 的语法和安全变体
基础语法极简，但加个 IF EXISTS 能避免脚本因库不存在而中断：
DROP DATABASE IF EXISTS <database_name>;</database_name>
注意：IF EXISTS 只 suppress 错误，不改变行为——它不会跳过权限检查，也不会自动断开连接。如果想更稳妥，可先查是否存在：
SELECT SCHEMA_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME = 'my_old_db';
另外，DROP DATABASE 等价于 DROP SCHEMA，两者完全互换，无任何功能差异。
删除后磁盘空间没立刻释放？别慌，这是 InnoDB 正常行为
执行成功不代表 .ibd 文件马上消失。InnoDB 默认使用共享表空间（ibdata1），删库只是标记空间可复用，物理文件大小不变。只有启用 innodb_file_per_table=ON（MySQL 5.6.6+ 默认开启）时，每个库的表才独占 .ibd 文件，删库后对应文件才被操作系统回收。
- 检查是否启用：执行
SHOW VARIABLES LIKE 'innodb_file_per_table';，返回ON才算真正“删即释放” - 如果仍是
OFF，删库后需重启 MySQL + 执行OPTIMIZE TABLE或导出再重建，才能压缩ibdata1 - 日志文件（
ib_logfile*）和二进制日志（binlog）不受影响，它们属于实例级资源，不随库删除而清理
权限残留是隐形地雷
DROP DATABASE 不动 mysql.db、mysql.tables_priv 这些权限表。如果之前给用户授过 my_old_db.* 的权限，删库后这些记录仍存在，下次建同名库时权限自动生效——可能造成越权访问。
- 删库后务必同步清理权限：用
DROP USER或REVOKE配合FLUSH PRIVILEGES - 典型操作链：
DROP DATABASE my_old_db;<br>REVOKE ALL PRIVILEGES ON my_old_db.* FROM 'app_user'@'%';<br>FLUSH PRIVILEGES;
- 尤其注意通配符授权，比如
GRANT SELECT ON `old_%`.* TO ...，删了old_v1，old_v2还在，但权限记录不会自动过滤
真正的“彻底”不是命令敲得有多狠，而是删库、清权限、断连接、验磁盘这四步都走到位。少一步，后面就容易冒出一个说不清道不明的“为什么又连上了”。
