test数据库应直接删除而非清理，因其无业务价值且扩大攻击面；执行drop database test可彻底清除该库及所有关联对象，但须确保当前未连接该库、具备drop权限，并同步清理匿名用户及检查配置防再生。
test 数据库不是用来“清理”的，而是该直接删除——它没有业务价值，只增加攻击面。
drop database test 是唯一有效操作
MySQL 安装后默认创建的 test 数据库，不承载任何真实业务，但允许匿名用户或低权限用户连接并执行查询。攻击者常利用它试探权限、加载恶意文件（如配合 LOAD DATA LOCAL INFILE），甚至作为 SQL 注入的跳板。
-
drop database test是标准且不可逆的操作，执行后该库及其所有表、数据、权限记录一并清除 - 必须用具备
DROP权限的账号执行（通常是root或管理员账号） - 执行前务必确认当前未连接到
test库：运行SELECT DATABASE();，返回NULL或其他库名才安全 - 别用
rm -rf直接删数据目录文件——MySQL 不会同步元数据，下次启动可能报错或自动重建
为什么不能只“禁用”或“清空”？
清空表（TRUNCATE TABLE）或撤回权限（REVOKE）都不够彻底：
-
test库本身存在，就允许用户USE test;，后续仍可建新表、写数据 - MySQL 5.7+ 默认允许
''@'localhost'这类空用户名账户访问test，只要库存在，这类漏洞就生效 -
skip-test-db配置项在 MySQL 8.0 中已被移除，5.7 及更早版本也仅阻止新建，不删除已有库
删除后还要防再生
单纯删一次不够，得堵住自动重建的路径：
- 检查并删除空用户：
SELECT user, host FROM mysql.user WHERE user = '';，再对每个结果执行DROP USER ''@'host'; - 确认配置文件（如
/etc/my.cnf）中没有init-file指向会重建test的 SQL 脚本 - 若使用容器部署（如 Docker），确保启动命令或初始化脚本里没包含
CREATE DATABASE test; - 定期巡检：
SHOW DATABASES LIKE 'test';—— 返回空集才算真正消失
最易被忽略的是空用户残留：哪怕 test 库删了，只要 ''@'localhost' 还在，攻击者就能连上 MySQL 并尝试跨库操作或提权。删库只是第一步，清理用户和验证配置才是闭环。
