删除 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获得所需库表权限。
真正危险的不是删用户，而是删用户后没同步更新所有调用方的连接参数，或者误以为删用户等于“清空业务数据”。
