Operation denied本质是MySQL 8.0在--skip-grant-tables模式下仍拦截非法DML或状态异常的ALTER USER操作；必须严格按FLUSH PRIVILEGES→ALTER USER指定plugin→再FLUSH PRIVILEGES三步闭环执行，且确保服务停净、datadir正确、以管理员身份运行。
Operation denied 本质是权限系统拒绝了当前会话执行密码修改操作，不是语法错、也不是连接失败，而是 MySQL 8.0 的权限校验在“跳过权限表”模式下仍对部分写操作做了硬性拦截 —— 尤其当你误用 UPDATE user 直接改表、或没先执行 FLUSH PRIVILEGES 就直接 ALTER USER 时，就会触发这个报错。
为什么 ALTER USER 会报 Operation denied
MySQL 8.0 在 --skip-grant-tables 模式下虽不校验登录权限，但内部仍限制对系统表的直接 DML（如 UPDATE mysql.user），且 ALTER USER 依赖权限缓存状态。若缓存未刷新、或用户记录处于异常认证状态（比如 authentication_string 为空但 plugin 是 caching_sha2_password），ALTER USER 就会被拒绝。
- 常见触发场景：执行
ALTER USER 'root'@'localhost' IDENTIFIED BY 'xxx'前，没先运行FLUSH PRIVILEGES - 错误组合：先
UPDATE user SET authentication_string = ''，但没改plugin字段，再直接ALTER USER→ 报Operation denied - 被忽略的前提：必须先
USE mysql，否则ALTER USER可能因上下文缺失而失败
正确重置密码的三步闭环（缺一不可）
这不是“选一个命令就行”的问题，而是一组有严格顺序的操作链：
- 第一步：进入 MySQL 后立刻执行
FLUSH PRIVILEGES—— 强制加载当前内存权限状态，让后续ALTER USER有据可依 - 第二步：显式指定插件，用
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '新密码'—— 避开caching_sha2_password对空密码或弱密码的额外校验 - 第三步：再次执行
FLUSH PRIVILEGES—— 确保新认证方式立即载入运行时，否则重启后可能回退到旧状态
容易被忽略的 Windows 路径与服务名细节
报 Operation denied 有时根本不是 SQL 层问题，而是底层服务没真正停干净，或 mysqld 启动时用了错误 datadir 导致读到旧 user 表：
- 务必确认服务已停止：
net stop MySQL80（服务名要和services.msc里显示的一致，可能是MySQL80、MySQL或自定义名） - 启动
mysqld --skip-grant-tables时，必须带--datadir参数指向真实数据目录（通常是C:\ProgramData\MySQL\MySQL Server 8.0\Data，不是Program Files下的安装目录） - 两个 CMD 窗口都必须以管理员身份运行 —— 否则 Windows 共享内存（
--shared-memory）会静默失败，导致看似启动成功，实则权限绕过无效
最常卡住的地方，是以为 mysqld --console --skip-grant-tables --shared-memory 执行完就万事大吉，却没检查它是否真的加载了正确的 datadir；或者在第二个窗口执行 mysql -u root 后，忘了 USE mysql 就直接敲 ALTER USER —— 这些微小遗漏，都会让 MySQL 返回冷冰冰的 Operation denied，而不是更具体的提示。
