mysql.user表字段数不匹配需运行mysql_upgrade修复：该命令自动补全5.7新增字段如password_last_changed、account_locked等，执行后必须重启mysql服务。
mysql.user 表字段数对不上：Expected 45, found 42/43
这是 MySQL 5.7 升级后最典型的系统表结构不一致问题。报错 ERROR 1805 (HY000): Column count of mysql.user is wrong. Expected 45, found 42 意味着当前 mysql.user 表只有 42 列，但 MySQL 5.7 运行时预期是 45 列——说明表结构没跟上版本升级。
常见诱因包括：
- 用
mysqldump --all-databases导出再导入的方式迁移了旧版本（如 5.5 或 5.6）的mysql库，直接覆盖了新版本的系统表 - 跳过了
mysql_upgrade步骤，尤其是从 5.6 升级到 5.7 时 - 手动修改过
mysql.user表结构（极不推荐）
注意：CHECK TABLE mysql.user 返回 OK 并不能说明结构正确，它只校验物理完整性，不校验字段定义是否匹配当前版本要求。
必须运行 mysql_upgrade，不是可选项
mysql_upgrade 不是“检查工具”，而是实际执行系统表结构变更和数据迁移的命令。它会对比当前二进制版本与 mysql 库中各表的元数据，自动补列、改类型、更新默认值——比如为 5.7 新增的 password_last_changed、account_locked 等字段。
执行前确认几点：
- MySQL 服务正在运行（
systemctl status mysqld） - 你有
root用户且密码可用（或能免密登录） - 不要在备份导入后跳过这步，哪怕看起来“一切正常”
典型命令：
mysql_upgrade -uroot -p -S /var/lib/mysql/mysql.sock
成功输出里应包含类似 mysql.user OK 的行。完成后必须重启 MySQL（systemctl restart mysqld），否则新字段不会被加载进内存缓存。
创建用户失败还可能是 validate_password 插件拦截
如果报错变成 ERROR 1819 (HY000): Your password does not satisfy the current policy requirements，那和表结构无关，是密码强度插件在起作用。
MySQL 5.7 默认启用 validate_password，它会拒绝短密码、纯数字、无大小写混合等“弱口令”。这时 CREATE USER 直接失败，连表结构校验环节都进不去。
临时绕过方式（仅限测试环境）：
- 登录后执行
SET GLOBAL validate_password_policy=LOW; - 或彻底禁用：在
my.cnf的[mysqld]段下加plugin-load-add=validate_password.so→ 改成注释，再重启
生产环境别删插件，应按策略设合规密码，比如 'MyPassw0rd!2026'。
新用户连上去看不到库或表，不是创建失败，是权限为空
成功执行 CREATE USER 'u1'@'localhost' IDENTIFIED BY 'xxx'; 后，该用户确实存在，但 mysql.user 表里所有 *_priv 字段都是 N，意味着零权限。此时连接成功，但 SHOW DATABASES; 只能看到 information_schema，SELECT 任何业务表都会报 Access denied。
必须显式授权：
- 只读某库：
GRANT SELECT ON mydb.* TO 'u1'@'localhost'; - 建表+读写：
GRANT CREATE, SELECT, INSERT, UPDATE, DELETE ON mydb.* TO 'u1'@'localhost'; - 最后别忘：
FLUSH PRIVILEGES;（虽然 5.7 多数情况自动刷新，但加上更稳）
容易忽略的一点：授权语句里的 host 必须和 CREATE USER 时完全一致（包括 '%' 和 'localhost' 的区别），否则权限不生效。
