删用户权限后仍生效，是因为权限缓存未刷新；必须执行FLUSH PRIVILEGES强制重载mysql.user等权限表至内存，且已存在连接需重连才应用新权限。
删了用户权限但还生效，不是没删干净，而是权限缓存没刷新。 MySQL 的权限系统不会实时重载，必须显式通知服务器重新加载权限表，否则 DELETE 或 DROP USER 后的变更只存在于磁盘（mysql.user 等表），不自动生效到内存中的权限缓存。
执行 FLUSH PRIVILEGES 是唯一可靠刷新方式
MySQL 不会在你改完 mysql 库表后自动 reload，必须手动触发。注意这不是“可选操作”，而是强制步骤：
-
FLUSH PRIVILEGES会重新读取mysql.user、mysql.db、mysql.tables_priv等所有权限表，覆盖内存缓存 - 仅对当前连接有效 —— 已建立的活跃连接仍保留旧权限，新连接或重新认证后才应用新规则
- 不能用
RELOAD权限以外的账号执行，否则报错Access denied; you need (at least one of) the RELOAD privilege(s) for this operation
删用户时用 DROP USER 比直接删表更安全
直接 DELETE FROM mysql.user WHERE User='xxx' 容易遗漏关联权限表（如 mysql.procs_priv），且不自动触发任何清理逻辑：
-
DROP USER 'xxx'@'host'会原子性地清除所有相关记录（用户、数据库级、表级、列级、存储过程级权限） - 但
DROP USER本身也不刷新缓存，仍需紧跟FLUSH PRIVILEGES - MySQL 8.0+ 支持
DROP USER IF EXISTS，避免误删报错
确认权限是否真正失效的验证方法
别只看 SELECT * FROM mysql.user，要实测行为：
- 用该用户重新连接：
mysql -u xxx -p，再执行原被授权的操作（比如SELECT * FROM sensitive_table） - 检查错误信息是否变成
ERROR 1142 (42000): SELECT command denied to user 'xxx'@'%' for table 'sensitive_table' - 如果仍能执行，说明要么没
FLUSH PRIVILEGES，要么连接复用了旧认证上下文（比如连接池未断连）
最容易被忽略的是：即使权限已删、也执行了 FLUSH PRIVILEGES，只要旧连接没断开，它就继续持有原来那套权限。生产环境务必让应用重启连接或等待连接池自然回收，否则“删了没用”是常态。
