MySQL 5.7如何通过修改user表直接更新用户权限及存在哪些风险？

直接UPDATE mysql.user表能改权限但不推荐，因多数权限字段仅为全局开关，实际生效需配套db、tables_priv等表，单独修改易导致权限错位或被忽略；且必须执行FLUSH PRIVILEGES才生效，否则修改无效。

直接 UPDATE mysql.user 表能改权限，但不推荐

能改，但多数权限字段（如 Select_priv、Insert_priv）只是「全局开关」，实际生效依赖 db、tables_priv 等配套表，单独改 user 表容易造成权限错位或被忽略。

例如：把 Select_priv='Y' 写进 user 表，不代表该用户真能查任意库——它只影响 *.* 级别权限；若没在 db 表里配对应库的记录，SELECT 仍会拒绝。

1. user 表里的权限字段（如 Super_priv、Grant_priv）只控制全局操作能力，不控制具体库/表访问
2. 库级权限存在 mysql.db 表，表级在 mysql.tables_priv，列级在 mysql.columns_priv
3. MySQL 启动时加载这些表到内存缓存，UPDATE 后必须执行 FLUSH PRIVILEGES 才生效，否则修改无效

authentication_string 字段必须用 password() 函数加密

MySQL 5.7 废弃了 Password 字段，密码统一存进 authentication_string，且该字段值不是明文，也不是随便哈希——必须用内置 PASSWORD() 函数生成，否则登录会报 Access denied。

错误写法：UPDATE mysql.user SET authentication_string = 'mypassword123' WHERE user='test'; → 登录失败

正确写法：UPDATE mysql.user SET authentication_string = PASSWORD('mypassword123') WHERE user='test';

1. PASSWORD() 是 MySQL 5.7 的兼容函数，生成的是 mysql_native_password 插件所需的 hash 格式
2. 如果账户 plugin 字段为空或为 mysql_old_password，即使密码对也登录不了，需同步执行：UPDATE mysql.user SET plugin='mysql_native_password' WHERE user='test';
3. 执行完必须 FLUSH PRIVILEGES，否则新密码不生效

SQL_SAFE_UPDATES 开关常导致 UPDATE 失败

直接更新 mysql.user 时，如果没带主键条件（比如只写 WHERE user='test' 但 user+host 才是联合主键），MySQL 会因启用安全模式而拒绝执行，报错：Error Code: 1175. You are using safe update mode...

这不是权限问题，是 MySQL 自身保护机制。绕过方法只有临时关闭：

1. 先查当前状态：SHOW VARIABLES LIKE 'SQL_SAFE_UPDATES';
2. 临时禁用：SET SQL_SAFE_UPDATES = 0;
3. 执行你的 UPDATE（务必带上完整条件，如 WHERE user='test' AND host='localhost'）
4. 改完立刻恢复：SET SQL_SAFE_UPDATES = 1;，避免后续误操作

权限变更后 FLUSH PRIVILEGES 不是万能解药

FLUSH PRIVILEGES 确实让 MySQL 重载权限表，但它不解决三类典型问题：

1. 客户端连接已建立，旧连接仍按原权限运行——新权限只对新建连接生效
2. 如果用户正在执行长事务或持有锁，FLUSH 不中断其会话，权限不会“热切换”
3. 某些权限（如 RELOAD、SHUTDOWN）需要用户重新登录才体现，FLUSH 本身不触发 session 权限刷新

真正稳妥的做法是：改完权限 → FLUSH PRIVILEGES → 让应用断开重连，或手动 kill 对应连接：KILL CONNECTION <id>;

最易被忽略的一点：MySQL 5.7 默认开启 sql_mode=STRICT_TRANS_TABLES，如果 UPDATE 语句字段类型不匹配（比如往 authentication_string 写超长字符串），会静默截断而非报错，导致密码变空或不可用——务必检查 ROW_COUNT() 和实际更新行数是否一致。