删除 MySQL 用户不会删除数据库或表数据，仅移除认证信息和权限记录；推荐使用 DROP USER 命令，它自动清理授权表并刷新权限；误删高权限用户可能导致管理功能失效，需确保至少一个管理员账号可用；应用连接报 Access denied 是因配置未更新，非数据丢失。
删除 MySQL 用户不会删除数据库或表数据
MySQL 的用户账号和数据库对象（如 database、table、view）是完全分离的。执行 DROP USER 或 DELETE FROM mysql.user 只会移除认证信息和权限记录，不影响任何实际存储的数据。
但要注意：如果该用户拥有某个数据库的 OWNER 级别权限（比如通过 GRANT ALL ON db.* TO 'user'@'host'），删掉用户后，那些权限自然失效——但数据库本身仍存在，其他有权限的用户照常访问。
用 DROP USER 是安全且推荐的方式
MySQL 5.7+ 强烈建议用 DROP USER 而非手动删 mysql.user 表，原因包括：
-
DROP USER会自动清理关联的授权表（mysql.db、mysql.tables_priv等），手动删行容易遗漏 - 它会隐式执行
FLUSH PRIVILEGES，避免权限缓存不一致 - 不支持回滚（DDL 操作），所以执行前务必确认用户名和 host 匹配准确
示例：
DROP USER 'app_user'@'192.168.1.%';
注意：'app_user'@'localhost' 和 'app_user'@'%' 是两个不同用户，必须分别删除。
误删 root 或高权限用户可能导致无法登录
如果删掉了唯一具有 mysql.session、mysql.sys 或 SUPER 权限的账号，且没留其他管理员账户，会导致：
- 无法再执行
GRANT、CREATE USER等管理操作 - 某些系统视图（如
performance_schema）可能报错 - 需要重启 mysqld 并加
--skip-grant-tables才能修复
所以生产环境删用户前，务必确认至少还有一个具备 CREATE USER 和 GRANT OPTION 的账号在线。
删除用户后应用连接可能报 Access denied for user
这不是数据丢了，而是应用配置里还写着已删除的用户名。常见表现：
- 应用启动失败，日志出现
Access denied for user 'old_user'@'xxx' - 连接池持续重试，引发大量错误日志
- 部分服务降级或超时，但数据库本身无异常
解决方法很简单：更新应用配置中的 username 和 password，指向一个仍存在的、有对应权限的用户，并确保该用户已通过 GRANT 获得所需库表权限。
真正危险的不是删用户，而是删用户后没同步更新所有调用方的连接参数，或者误以为删用户等于“清空业务数据”。
