直接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 仍会拒绝。
-
user表里的权限字段（如Super_priv、Grant_priv）只控制全局操作能力，不控制具体库/表访问 - 库级权限存在
mysql.db表，表级在mysql.tables_priv，列级在mysql.columns_priv - 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';
-
PASSWORD()是 MySQL 5.7 的兼容函数，生成的是mysql_native_password插件所需的 hash 格式 - 如果账户
plugin字段为空或为mysql_old_password，即使密码对也登录不了，需同步执行：UPDATE mysql.user SET plugin='mysql_native_password' WHERE user='test'; - 执行完必须
FLUSH PRIVILEGES，否则新密码不生效
SQL_SAFE_UPDATES 开关常导致 UPDATE 失败
直接更新 mysql.user 时，如果没带主键条件（比如只写 WHERE user='test' 但 user+host 才是联合主键），MySQL 会因启用安全模式而拒绝执行，报错：Error Code: 1175. You are using safe update mode...
这不是权限问题，是 MySQL 自身保护机制。绕过方法只有临时关闭：
- 先查当前状态：
SHOW VARIABLES LIKE 'SQL_SAFE_UPDATES'; - 临时禁用：
SET SQL_SAFE_UPDATES = 0; - 执行你的
UPDATE（务必带上完整条件，如WHERE user='test' AND host='localhost'） - 改完立刻恢复：
SET SQL_SAFE_UPDATES = 1;，避免后续误操作
权限变更后 FLUSH PRIVILEGES 不是万能解药
FLUSH PRIVILEGES 确实让 MySQL 重载权限表，但它不解决三类典型问题：
- 客户端连接已建立，旧连接仍按原权限运行——新权限只对新建连接生效
- 如果用户正在执行长事务或持有锁，
FLUSH不中断其会话，权限不会“热切换” - 某些权限（如
RELOAD、SHUTDOWN）需要用户重新登录才体现，FLUSH本身不触发 session 权限刷新
真正稳妥的做法是：改完权限 → FLUSH PRIVILEGES → 让应用断开重连，或手动 kill 对应连接：KILL CONNECTION <id>;</id>
最易被忽略的一点：MySQL 5.7 默认开启 sql_mode=STRICT_TRANS_TABLES，如果 UPDATE 语句字段类型不匹配（比如往 authentication_string 写超长字符串），会静默截断而非报错，导致密码变空或不可用——务必检查 ROW_COUNT() 和实际更新行数是否一致。
