直接update mysql.user表无效，因mysql 8.0+权限加载进内存后仅响应grant/alter user等ddl自动刷新，手动改表不触发缓存更新且易写错authentication_string与plugin字段。
直接 UPDATE mysql.user 表为什么没反应
MySQL 8.0+ 启动时把权限加载进内存，后续只响应 GRANT、ALTER USER 或 DROP USER 这类 DDL 语句触发的自动刷新。你用 UPDATE mysql.user SET authentication_string = ... 改了磁盘上的数据，但内存里的权限快照完全没变，新连接仍按旧值校验——所以“改了等于没改”。更糟的是，authentication_string 字段在 8.0 中必须是 SHA256 哈希格式，且和 plugin 字段强绑定；手动拼错一个字符，用户就永久无法登录。
FLUSH PRIVILEGES 还不生效？先看这三点
执行了 FLUSH PRIVILEGES 却依旧连不上或权限不对，大概率卡在这几个地方：
-
Host和User匹配不精确：比如你改的是'app'@'10.0.1.%'，但客户端实际连的是'app'@'10.0.1.123'，而 MySQL 按最长前缀匹配，若存在'app'@'10.0.1.123'这行记录，它会优先用那行——根本不会读你刚改的通配行 -
plugin字段被手改成mysql_native_password，但客户端没显式指定--default-auth=mysql_native_password，服务端默认用caching_sha2_password尝试握手，失败后静默拒绝，不报错也不提示 -
FLUSH PRIVILEGES只影响后续新建连接；已存在的连接（包括你当前这个 MySQL CLI 会话）权限快照不会更新，必须退出重连
该用什么命令安全改权限
所有操作都走标准语法，让 MySQL 自己处理哈希生成、缓存刷新、关联表清理：
- 改密码：
ALTER USER 'u'@'h' IDENTIFIED BY 'newpwd';（8.0+ 必用，SET PASSWORD已弃用） - 增删权限：
GRANT SELECT, INSERT ON db.tbl TO 'u'@'h';或REVOKE INSERT ON db.tbl FROM 'u'@'h';（注意：GRANT不保留旧权限，只设列出的；要叠加用GRANT多次） - 删用户：
DROP USER 'u'@'h';（别用DELETE FROM mysql.user，它漏删mysql.db、mysql.tables_priv等关联行，导致权限残留） - 批量授权（8.0+）：
CREATE ROLE 'dev_role'; GRANT SELECT, UPDATE ON app.* TO 'dev_role'; GRANT 'dev_role' TO 'u1'@'%', 'u2'@'%';（之后所有权限调整只动角色定义，用户自动继承）
系统表引擎损坏导致权限操作全挂
从 5.7 升级到 8.0 时若直接恢复含系统表的备份，mysql.user、mysql.db 可能仍是 MyISAM 引擎，而 8.0 要求必须是 InnoDB。现象是 CREATE USER 报错、GRANT 无响应、甚至 SHOW TABLES 都卡住。
修复步骤（需停服）：
- 用
mysqld --skip-grant-tables --shared-memory启动（Windows 加--console，Linux 加--skip-networking） - 免密登录后执行：
USE mysql; ALTER TABLE user ENGINE=InnoDB; ALTER TABLE db ENGINE=InnoDB; FLUSH PRIVILEGES; - 杀掉 mysqld 进程，正常重启服务
- 验证：
mysql -e "USE mysql; SHOW TABLE STATUS LIKE 'user'\G" | grep Engine，输出应为Engine: InnoDB
真正容易被忽略的是：哪怕你只改了一个用户的密码，只要系统表引擎不是 InnoDB，整个权限链就不可靠——这不是缓存问题，是底层存储机制不兼容。
