先查 test 账号是否存在于 mysql.user 表中：select user, host from mysql.user where user = 'test';再清理 mysql.db 和 mysql.tables_priv 中残留权限，最后处理 test 库视图 definer 及应用层硬编码。
查清 test 账号是否还存在于 mysql.user 表中
很多清理失败的起点是误以为 DROP USER 已清空一切，其实 test 用户可能根本没被删过。执行 DROP USER IF EXISTS 'test'@'localhost' 或 'test'@'%' 前，先确认它是否存在：
SELECT User, Host FROM mysql.user WHERE User = 'test';
注意：MySQL 默认安装后常带 ''@'localhost'（匿名用户）和 'test'@'localhost'，但这两个不是一回事，别漏查。
删完 test 账号后，mysql.db 和 mysql.tables_priv 里仍有残留权限
DROP USER 只删 mysql.user 行，不自动清理库级、表级权限记录。若曾执行过 GRANT SELECT ON test.* TO 'app'@'%'，删掉 test 用户本身不影响这些授权，但更常见的是：你删的是 'test'@'localhost'，而权限却挂在 'test'@'%' 上——host 不匹配导致静默失效。
必须手动检查并清理：
-
SELECT * FROM mysql.db WHERE User = 'test';—— 若有结果，执行DELETE FROM mysql.db WHERE User = 'test'; -
SELECT * FROM mysql.tables_priv WHERE User = 'test';—— 同样，非空则DELETE FROM mysql.tables_priv WHERE User = 'test'; - 执行完后必须
FLUSH PRIVILEGES;，否则内存缓存未更新，SHOW GRANTS还会显示旧权限
test 数据库里的视图残留需单独处理
视图（VIEW）是对象，不是权限，不会随用户删除而消失。如果 test 用户创建过视图（比如 CREATE VIEW v_orders AS SELECT ...），这些视图仍保留在 test 库中，且定义里可能含 DEFINER='test'@'localhost' —— 即使用户已删，视图还能查，但一旦重建同名用户或执行 ALTER VIEW 就会报错“DEFINER does not exist”。
查所有 test 库下的视图及其 DEFINER：
SELECT TABLE_NAME, DEFINER FROM information_schema.VIEWS WHERE TABLE_SCHEMA = 'test';
处理方式分两种：
- 若确定不再需要 test 库，直接
DROP DATABASE test;（比逐个删视图快，且一并清空表、函数、存储过程） - 若 test 库要保留，但想清理 DEFINER，需逐个
ALTER VIEW v_name AS ... DEFINER=CURRENT_USER或设为安全值如DEFINER='root'@'localhost'
别忽略 performance_schema 和 INFORMATION_SCHEMA 的间接引用
有些监控脚本或审计工具会读 performance_schema.threads 或 INFORMATION_SCHEMA.PROCESSLIST 并按 USER 字段过滤，若残留 test 用户的历史连接记录（尤其 LAST_SEEN 时间戳还在），可能触发误告警。这不是权限问题，但属于“逻辑残留”。
这类数据无需也不应手动删 —— performance_schema 是内存表，重启 mysqld 即清空；INFORMATION_SCHEMA 是只读视图，无法写入。真正要盯的是：
– 是否还有应用配置里硬编码了 test 用户（如 JDBC URL、连接池配置）
– 是否有定时任务仍在用 test 账号连库（查 mysql.schemata 或慢日志可辅助定位）
– test 是否被设为某账号的 DEFAULT ROLE（查 mysql.role_edges WHERE TO_ROLE = 'test'，虽然 test 通常不是角色名，但命名不规范时可能撞上）
