mysql.user 表位于 mysql 系统数据库中，存储全局权限、认证信息和账号状态，不可删除；查用户权限需用 SHOW GRANTS，修改须用 ALTER USER 而非直接 UPDATE。
mysql
.user 表在哪个数据库里
它就在
数据库里，是系统自带的、不可删的表。不是你建的库，也不是临时表，所有用户账号（包括 root）的全局权限都存在这里。
常见错误现象：执行
报错
——因为没指定库，MySQL 默认查当前库，而
表只在
库下。
必须显式用
连接时若未指定库，也得先
再查
低版本（5.7 及以前）字段名和 8.0 差异大，比如
字段在 8.0 已被
替代
查用户权限为什么不能只看 mysql.user
只存全局权限（比如
、
），但实际权限是叠加生效的：库级、表级、列级、甚至存储过程权限，分别存在
、
、
等表里。
使用场景：你给用户
，他在
里对应字段仍是
，权限却真实存在——因为记录在
里。
查完整权限要用
，它自动聚合所有层级
直接查
只适合确认是否具备全局 DDL 权限（如
）、是否允许登录（
）、认证方式（
）
8.0 后新增
和
，角色权限也不在
表里
修改 mysql.user 表会怎样
不建议直接
。MySQL 不保证这类操作的原子性或一致性，尤其涉及密码哈希、插件字段时，极易导致用户无法登录或权限异常。
MySQL（Linux）
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
下载
典型翻车点：手动 UPDATE
值写错格式（比如该用
却填了明文），或漏设
字段，结果用户连不上，且错误日志只报
，不提示具体原因。
改密码请用
锁账号用
（比 UPDATE
安全）
刷新权限必须
，但用
语句则自动触发，无需手刷
mysql.user 表结构在不同版本的关键差异
5.7 和 8.0 的
字段数量差了一倍多，8.0 新增了密码过期、历史限制、失败登录跟踪等安全字段，老脚本直连 8.0 很容易因字段缺失或类型不匹配出错。
性能影响：8.0 的
表默认引擎是
（5.7 是
），支持事务和行锁，但字段变多后，全表扫描更慢；高并发认证场景下，过度依赖
查询可能成瓶颈。
5.7 关键字段：
,
,
,
,
8.0 关键新增：
,
,
,
,
兼容写法：查用户是否存在，别依赖字段偏移，始终用列名，例如
真正难的不是找到这张表，而是意识到：它只是权限拼图的第一块，而且每块的形状在升级后都可能变。字段名、默认值、甚至校验逻辑，都在 quietly 改动。
mysqlSELECT * FROM user;Table 'xxx.user' doesn't existusermysqlSELECT * FROM mysql.user;USE mysql;passwordauthentication_stringmysql.userSELECT_privInsert_privmysql.dbmysql.tables_privmysql.columns_privGRANT SELECT ON test.* TO 'u1'@'%';mysql.userNmysql.dbSHOW GRANTS FOR 'u1'@'%';mysql.userCreate_privaccount_lockedpluginmysql.role_edgesmysql.default_rolesuserUPDATE mysql.userauthentication_stringSHA256_PASSWORDpluginAccess deniedALTER USER 'u1'@'%' IDENTIFIED BY 'xxx';ALTER USER 'u1'@'%' ACCOUNT LOCK;account_locked='Y'FLUSH PRIVILEGES;CREATE/GRANT/ALTER USERmysql.usermysql.userInnoDBMyISAMmysql.userUserHostpasswordSelect_privssl_typeaccount_lockedpassword_last_changedpassword_lifetimefailed_login_attemptspassword_reuse_historySELECT Host,User FROM mysql.user WHERE User='root';