MySQL 8.0 权限模型变更导致 GRANT 失败
MySQL 8.0 彻底弃用了
mysql.user表的直接更新方式，改用基于角色（
ROLE）和分层权限（
CREATE USER+
GRANT）的严格模型。如果你在升级后执行类似
GRANT ALL ON *.* TO 'admin'@'%'却报错
ERROR 1410 (42000): You are not allowed to create a user with GRANT，说明当前用户缺少
CREATE USER权限，或未显式创建用户。
实操建议：
必须先用CREATE USER显式建用户，再
GRANT：
CREATE USER 'app_user'@'localhost' IDENTIFIED BY 'strong_pass_2024'; GRANT SELECT, INSERT ON mydb.* TO 'app_user'@'localhost';旧版
INSERT INTO mysql.user或
UPDATE mysql.user直接写表的方式在 8.0+ 会失败，且可能破坏数据字典一致性
root用户默认不再拥有
ALL PRIVILEGES的隐式继承；升级后需手动确认其权限是否完整：
SHOW GRANTS FOR 'root'@'localhost';
authentication_plugin 默认改为 caching_sha2_password
MySQL 8.0+ 默认认证插件从
mysql_native_password改为
caching_sha2_password，这会导致老版本客户端（如 MySQL 5.7 客户端、某些 Python 2 的
mysql-python驱动、旧版 Navicat）连接失败，错误提示常为
Client does not support authentication protocol requested by server。
实操建议：
临时兼容旧客户端：建用户时指定旧插件：CREATE USER 'legacy_app'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd123';长期应升级客户端驱动 —— Python 推荐换用
pymysql或
mysql-connector-python >= 8.0.12；Java 应用需使用
mysql-connector-j >= 8.0.16全局修改默认插件风险高，不建议改
default_authentication_plugin配置项，容易引发管理账号登录异常
系统数据库（mysql / sys / performance_schema）权限被进一步收紧
MySQL 8.0 对
mysql系统库的访问控制更细粒度，默认普通用户即使有
SELECT权限也无法查询
mysql.user表（返回空结果），而只能通过
SHOW GRANTS或
INFORMATION_SCHEMA查看自身权限。这是安全加固措施，不是 bug。
实操建议：
不要依赖SELECT * FROM mysql.user做权限审计；改用
SELECT * FROM INFORMATION_SCHEMA.ROLE_TABLE_GRANTS或
SHOW GRANTS FOR CURRENT_USER监控类工具（如 Zabbix、Prometheus exporter）若需读取
performance_schema，必须显式授权：
GRANT SELECT ON performance_schema.* TO 'monitor'@'localhost';
SYS数据库默认只对
root和具有
SYSTEM_VARIABLES_ADMIN权限的用户可见；普通 DBA 账号需额外授权才能运行
SYS视图
升级后必须重置 root 密码并验证账户锁定策略
MySQL 8.0 引入了账户锁定（
ACCOUNT LOCK）与失败登录跟踪机制。升级过程中若原
root密码为空或弱口令，新版本可能自动启用
password_history或触发
FAILED_LOGIN_ATTEMPTS锁定，导致无法登录。
实操建议：
升级后第一时间用安全模式启动并重置root：
mysqld --skip-grant-tables --skip-networking，然后执行
ALTER USER 'root'@'localhost' IDENTIFIED BY 'new_strong_pass';检查账户状态：
SELECT user, host, account_locked, password_last_changed FROM mysql.user;若需禁用锁定策略（仅测试环境），可在配置中加：
default_password_lifetime = 0和
lock_wait_timeout = 31536000，但生产环境应保留锁定能力
密码策略、插件兼容性、权限可见性这三处最容易在升级后“静默失效”——不是报错，而是功能行为变了，得主动查、不能凭经验猜。
