DROP USER命令必须指定用户名和主机名（如'DROP USER 'alice'@'localhost'）才能正确删除用户，否则报语法错误；该操作会级联清除权限但不删除用户创建的数据库，且不可回滚。
drop user 命令必须带主机名，否则可能删错人
MySQL 的用户由 username@hostname 共同唯一标识，不是只看用户名。执行 DROP USER 'alice' 会报错，因为语法不合法；正确写法必须包含主机部分，比如 DROP USER 'alice'@'localhost' 或 DROP USER 'alice'@'%'。
常见错误现象：执行 DROP USER 'alice' 报错 ERROR 1396 (HY000): Operation DROP USER failed for 'alice'@'%' —— 实际是语法错误，不是用户不存在。
- 如果不确定用户绑定的主机名，先查
SELECT User, Host FROM mysql.user WHERE User = 'alice'; - 通配符
%表示任意主机，localhost和127.0.0.1在 MySQL 中是两个不同用户，不能互相替代 - 删除前建议用
SHOW GRANTS FOR 'alice'@'localhost';确认权限范围，避免误删关键运维账号
DROP USER 会级联清理权限，但不会自动删数据库
DROP USER 会自动从 mysql.user、mysql.db、mysql.tables_priv 等系统表中清除该用户所有权限记录，不需要手动清 GRANTS。
但它**完全不碰用户创建的数据库或表**。比如用户 'bob'@'%' 自己建了数据库 bob_app，执行 DROP USER 'bob'@'%' 后，bob_app 依然存在，且所有权不会转移 —— 这个库变成“无主”状态，后续只能由 root 或其他有 CREATE 权限的用户来删或接管。
- 若想一并清理用户专属库，得额外执行
DROP DATABASE `bob_app`; - 注意反引号包裹数据库名，防止库名含特殊字符或关键字时报错
- MySQL 8.0+ 不再支持
DROP USER IF EXISTS的旧写法（已废弃），统一用DROP USER IF EXISTS 'user'@'host'
MySQL 5.7 和 8.0 在用户删除行为上有一处关键差异
MySQL 5.7 中，DROP USER 会同时清空用户的密码哈希值和认证插件信息；而 MySQL 8.0 默认使用 caching_sha2_password 插件，删除用户时只是移除记录，不会触发插件层的清理动作 —— 这本身没影响，但要注意配套行为：
- MySQL 8.0 删除用户后，若用相同用户名+主机重新
CREATE USER，会沿用新默认插件，无需额外指定IDENTIFIED WITH caching_sha2_password - 如果原用户用的是
mysql_native_password，重创建时得显式声明，否则客户端（尤其老版本 PHP/Python 驱动）可能连不上 - 删除操作本身在两个版本中都不可回滚，没有事务保障 —— 执行即生效，没确认提示
权限不足时 drop user 会静默失败还是报错？
必须拥有 SYSTEM_USER 权限（MySQL 8.0+）或 DELETE 权限作用于 mysql 库（5.7 及更早），否则直接报错：ERROR 1227 (42501): Access denied; you need (at least one of) the SYSTEM_USER privilege(s) for this operation。
特别容易被忽略的一点：普通 DBA 账号即使有 ALL PRIVILEGES ON *.*，也不等于自动获得 SYSTEM_USER —— 这是个独立权限，需显式授予：GRANT SYSTEM_USER ON *.* TO 'dba'@'localhost';
- root 用户默认拥有，但生产环境往往禁用 root 远程登录，这时得提前给运维账号授权
- 用
SHOW GRANTS FOR CURRENT_USER;检查当前会话是否具备该权限 - 权限变更后需执行
FLUSH PRIVILEGES;才生效（仅当直接改表时需要，GRANT 语句不用）
事情说清了就结束
