DELETE FROM mysql.user会失败，因MySQL 5.7+强制要求用DROP USER语句删除用户，直接删表会引发权限缓存不一致、残留授权记录及认证异常等故障。
为什么 DELETE FROM mysql.user 会失败？
直接执行 delete from mysql.user where user='xxx' 通常报错，比如 error 1396 (hy000): operation drop user failed 或权限拒绝。根本原因不是语法错，而是 mysql 5.7+ 默认启用 sql_mode=strict_trans_tables，且用户元数据被缓存，更关键的是：mysql 要求必须用 drop user 语句（而非 delete）来清理用户记录，否则权限系统不一致，后续可能引发认证异常。
phpMyAdmin 中安全删除高权限用户的正确步骤
不能绕过 MySQL 的用户管理机制。即使你有 root 权限，在 phpMyAdmin 的 SQL 标签页里也必须走标准流程：
- 先执行
DROP USER 'username'@'host'（注意单引号、@ 符号、主机名要完全匹配，比如'admin'@'%'或'admin'@'localhost'） - 如果提示
User does not exist，说明该用户在mysql.user表中已不存在，但可能残留了授权表（如mysql.db），此时需手动清理：DELETE FROM mysql.db WHERE User='username'，再执行FLUSH PRIVILEGES - 若用户正被连接占用，
DROP USER可能卡住或报错；先查活跃连接：SELECT ID, USER, HOST, COMMAND, TIME FROM information_schema.PROCESSLIST WHERE USER='username'，必要时用KILL [ID]终止
phpMyAdmin 界面操作的隐藏风险
通过「用户账户」页面点「删除」按钮看似方便，但它底层调用的仍是 DROP USER。问题出在界面默认只显示 User 和 Host 列，容易忽略同一用户名在不同 host（如 'root'@'127.0.0.1' 和 'root'@'localhost'）是两个独立用户。误删一个，另一个仍存在，还会导致权限混乱。
- 务必在「用户账户」列表页点击「编辑权限」，确认完整 Host 值，再勾选对应行删除
- 不要依赖「全选 + 删除」——phpMyAdmin 不校验 Host 差异，可能批量删错
- 删除后立即执行
FLUSH PRIVILEGES，否则旧权限缓存仍在生效
删完之后还要检查什么？
高权限用户（尤其是 root 或带 GRANT OPTION 的用户）删除后，常出现新用户无法创建、权限继承异常等问题。这不是删错了，而是残留的授权链没断干净：
- 检查
mysql.proxies_priv表：SELECT * FROM mysql.proxies_priv WHERE User='username' - 检查角色关联（MySQL 8.0+）：
SELECT * FROM mysql.role_edges WHERE TO_HOST='username' - 确认没有触发器或存储过程硬编码了该用户名（搜索
INFORMATION_SCHEMA.ROUTINES）
真正麻烦的从来不是删动作本身，而是删完才发现某个监控脚本或部署工具还依赖那个被删的账号——所以操作前，先 grep 代码库和配置文件里的用户名。
立即学习“PHP免费学习笔记（深入）”；
