DROP USER 报错 ERROR 1396 是因 host 不匹配（如 localhost 与 127.0.0.1 视为不同），需用 SELECT Host, User FROM mysql.user 确认真实值；ERROR 1227 是因缺少 SYSTEM_USER 权限，需显式授予并 FLUSH PRIVILEGES；删后须刷新权限且手动终止活跃连接。
DROP USER 执行后报错 ERROR 1396 或 ERROR 1227，不是语法写错了，而是权限、host 匹配或残留状态没清理干净
ERROR 1396 (HY000): Operation DROP USER failed for 'xxx'@'yyy'
这个错误最常见于 MySQL 8.0+，本质是 DROP USER 找不到完全匹配的用户记录——不是用户不存在，而是你写的 'user'@'host' 和实际存储的 host 字符串不一致。
- MySQL 会把
localhost和127.0.0.1当作两个独立 host，DROP USER 'user'@'localhost'不会影响'user'@'127.0.0.1' - 通配符如
'user'@'192.168.%'或'user'@'%.example.com'必须原样写出，少一个点、多一个空格都不行 - 用
SELECT Host, User FROM mysql.user WHERE User = 'xxx';确认真实值，别靠记忆写 - 如果查出来有多条同名 user，必须逐条
DROP USER，不能只删一条就以为完事
ERROR 1227 (42000): Access denied; you need SYSTEM_USER privilege
MySQL 8.0 引入了 SYSTEM_USER 权限，它控制谁可以管理用户（包括 DROP USER）。root 用户默认没有这个权限，除非显式授予过。
- 执行
SHOW GRANTS FOR CURRENT_USER;，看输出里有没有SYSTEM_USER - 如果没有，且你有
GRANT OPTION，可用GRANT SYSTEM_USER ON *.* TO CURRENT_USER;自己加 - 注意：
GRANT ALL PRIVILEGES不包含SYSTEM_USER，这是个独立权限，必须单独授 - 授完立刻
FLUSH PRIVILEGES;，否则新权限不生效
执行 DROP USER 后用户还能连上？
不是没删成功，而是连接没断、缓存没刷、或客户端复用了旧连接池。
-
DROP USER只删权限元数据，不主动 KILL 连接。正在使用的连接仍可继续，直到自然断开或被手动KILL - 删完必须执行
FLUSH PRIVILEGES;，否则服务端内存里的权限缓存还是旧的，新创建同名用户可能报 “User already exists” - 如果应用用连接池（如 HikariCP、Druid），池子里的旧连接会持续报
Access denied直到超时重建，这不是 MySQL 问题，得调客户端配置 - 验证是否真删干净：用
SELECT User, Host FROM mysql.user WHERE User = 'xxx';查表；再用新连接尝试登录，确认拒绝
为什么不用 DELETE FROM mysql.user？
直接删 mysql.user 表是危险操作，容易留坑。
-
DELETE FROM mysql.user只动一张表，但权限还分散在mysql.db、mysql.tables_priv、mysql.proxies_priv等多张表里，删不全就会权限残留 - MySQL 8.0+ 的
mysql.user表结构变了（比如多了account_locked、password_reuse_history字段），手删字段易出错 -
DROP USER是原子操作，自动清理所有关联权限记录，语义明确、兼容性好 - 唯一例外：调试权限系统底层时，才考虑直改表，且必须先备份 +
FLUSH PRIVILEGES;强制重载
真正容易被忽略的是 host 的精确匹配和 FLUSH PRIVILEGES 的强制触发时机——删完不刷，后续所有操作都可能表现异常，而且这种异常不会报错，只会静默失效。
