这些 mysql 数据库表包含授权信息：

有关静态和动态全局权限之间的差异的信息，请参阅 静态与动态权限。

在 MySQL 8.3 中，授予权限表使用 InnoDB 存储引擎并且是事务性的。在 MySQL 8.3 之前，授予权限表使用 MyISAM 存储引擎并且是非事务性的。该更改使得伴随着账户管理语句的行为发生变化，例如 CREATE USER 或 GRANT。以前，一个账户管理语句可以成功地命名多个用户，而现在，每个语句都是事务性的，或者成功地命名所有用户，或者回滚并且不产生任何效果。

每个授予权限表包含范围列和权限列：

此外，授予权限表可能包含用于其他目的的列，而不仅仅是范围或权限评估。

服务器使用授予权限表的方式如下：

服务器在启动时将授权表的内容读取到内存中。您可以通过发出 FLUSH PRIVILEGES 语句或执行 mysqladmin flush-privileges 或 mysqladmin reload 命令来重新加载授权表。授权表的更改将如 第 8.2.13 节，“何时生效的权限更改” 所示。

当您修改账户时，验证您的更改是否产生了预期的效果是一个好主意。要检查某个账户的权限，请使用 SHOW GRANTS 语句。例如，要确定用户名和主机名值为 bob 和 pc84.example.com 的账户的权限，请使用以下语句：

SHOW GRANTS FOR 'bob'@'pc84.example.com';

要显示账户的非权限属性，请使用 SHOW CREATE USER：

SHOW CREATE USER 'bob'@'pc84.example.com';

服务器在访问控制的第一和第二阶段使用 user 和 db 表（见 第 8.2 节，“访问控制和账户管理”）。以下是 user 和 db 表的列。

The user 表的 plugin 和 身份验证字符串 列存储身份验证插件和凭据信息。

服务器使用 plugin 列中的插件名称来验证连接尝试的账户。

The plugin 列不能为空。启动时和在执行 FLUSH PRIVILEGES 时，服务器检查 user 表行。对于任何空 plugin 列的行，服务器将写入错误日志的警告信息：

[Warning] User entry 'user_name'@'host_name' has an empty plugin
value. The user will be ignored and no one can login with this user
anymore.

要将插件分配给缺少插件的账户，请使用 ALTER USER 语句。

The 密码已过期 列允许 DBA 将账户密码设为过期，并要求用户重置密码。默认 密码已过期 值为 'N'，但可以使用 ALTER USER 语句将其设置为 'Y'。在账户密码过期后，在服务器的后续连接中执行的所有操作将导致错误，直到用户发出 ALTER USER 语句以建立新的账户密码。

密码最后更改时间 是一个 TIMESTAMP 列，指示密码最后更改的时间。该值仅对使用 MySQL 内置身份验证插件（mysql_native_password 已弃用，sha256_password 或 caching_sha2_password）的账户非空。对于其他账户，例如使用外部身份验证系统的账户，该值为空。

密码最后更改时间 由 CREATE USER、ALTER USER 和 SET PASSWORD 语句更新，并由 GRANT 语句创建账户或更改账户密码时更新。

password_lifetime 表示账户密码生命周期，以天为单位。如果密码超过生命周期（根据 password_last_changed 列评估），服务器将在客户端使用该账户连接时认为密码已过期。值 N 大于零意味着密码必须每 N 天更改一次。值为 0 禁用自动密码过期。如果值为 NULL（默认），则应用全局过期策略，如 default_password_lifetime 系统变量所定义。

account_locked 表示账户是否被锁定（见 第 8.2.20 节，“账户锁定”）。

Password_reuse_history 是账户的 PASSWORD HISTORY 选项的值，或者为 NULL，表示默认历史记录。

Password_reuse_time 是账户的 PASSWORD REUSE INTERVAL 选项的值，或者为 NULL，表示默认间隔。

Password_require_current 对应账户的 PASSWORD REQUIRE 选项的值，如下表所示。

User_attributes 是一个 JSON 格式的列，存储账户属性，而不是存储在其他列中。INFORMATION_SCHEMA 通过 USER_ATTRIBUTES 表公开这些属性。

The User_attributes 列可能包含以下属性：

如果没有应用属性，则 User_attributes 为 NULL。

示例：一个具有辅助密码和部分撤销数据库权限的账户在列值中具有 additional_password 和 Restrictions 属性：

mysql> SELECT User_attributes FROM mysql.User WHERE User = 'u'\G
*************************** 1. row ***************************
User_attributes: {"Restrictions":
                   [{"Database": "mysql", "Privileges": ["SELECT"]}],
                  "additional_password": "hashed_credentials"}

要确定哪些属性存在，请使用 JSON_KEYS() 函数：

SELECT User, Host, JSON_KEYS(User_attributes)
FROM mysql.user WHERE User_attributes IS NOT NULL;

要提取特定的属性，例如 Restrictions，请执行以下操作：

SELECT User, Host, User_attributes->>'$.Restrictions'
FROM mysql.user WHERE User_attributes->>'$.Restrictions' <> '';

以下是存储在 multi_factor_authentication 中的信息示例：

{
  "multi_factor_authentication": [
    {
      "plugin": "authentication_ldap_simple",
      "passwordless": 0,
      "authentication_string": "ldap auth string",
      "requires_registration": 0
    },
    {
      "plugin": "authentication_webauthn",
      "passwordless": 0,
      "authentication_string": "",
      "requires_registration": 1
    }
  ]
}

在访问控制的第二阶段，服务器执行请求验证，以确保每个客户端都具有足够的权限来发出每个请求。在 user 和 db 授予权表之外，服务器还可能会咨询 tables_priv 和 columns_priv 表，以便对涉及表的请求进行更细粒度的权限控制。这些表具有以下列。

Timestamp 和 Grantor 列分别设置为当前时间戳和 CURRENT_USER 值，但否则未使用。

对于涉及存储例程的请求验证，服务器可能会咨询 procs_priv 表，该表具有以下列。

Routine_type 列是一个 ENUM 列，具有 'FUNCTION' 或 'PROCEDURE' 值，以指示该行引用的例程类型。这使得可以单独授予函数和同名过程的权限。

Timestamp 和 Grantor 列未使用。

proxies_priv 表记录代理账户的信息。它具有以下列：

要使账户能够授予其他账户PROXY权限，它必须在proxies_priv表中有一行，With_grant设置为1，Proxied_host和Proxied_user设置为指示授予权限的账户或账户。例如，在MySQL安装期间创建的'root'@'localhost'账户在proxies_priv表中有一行，启用授予PROXY权限给''@''，即所有用户和所有主机。这使得root能够设置代理用户，以及将设置代理用户的权限委托给其他账户。见第8.2.19节，“代理用户”。

global_grants 表列出了当前分配给用户账户的动态全局权限。该表具有以下列：

default_roles 表列出了默认用户角色。它具有以下列：

role_edges 表列出了角色子图的边缘。它具有以下列：

password_history 表包含密码更改信息。它具有以下列：

password_history 表累积了每个账户的足够数量的非空密码，以便MySQL执行密码历史记录长度和重用间隔检查。密码更改尝试时自动修剪超出限制的条目。

如果账户被重命名，其条目将被重命名以匹配。如果账户被删除或其身份验证插件被更改，其条目将被删除。

授予权限表中的范围列包含字符串。每个列的默认值为空字符串。以下表显示每个列允许的字符数。

主机 和 代理主机 值在存储在授权表之前将被转换为小写。

对于访问检查目的，用户、代理用户、身份验证字符串、数据库 和 表名 值的比较是区分大小写的。比较 主机、代理主机、列名 和 例程名 值是不区分大小写的。

在 user 和 db 表中，每个权限在一个单独的列中被声明为 ENUM('N','Y') DEFAULT 'N'。换言之，每个权限可以被禁用或启用，默认情况下是禁用。

在 tables_priv、columns_priv 和 procs_priv 表中，权限列被声明为 SET 列。这些列中的值可以包含表控制的任何权限组合。只有列值中列出的权限被启用。

只有 user 和 global_grants 表指定了管理权限，如 RELOAD、SHUTDOWN 和 SYSTEM_VARIABLES_ADMIN。管理操作是对服务器本身的操作，而不是数据库特定的，因此没有理由在其他授权表中列出这些权限。因此，服务器只需要咨询 user 和 global_grants 表来确定用户是否可以执行管理操作。

FILE 权限也只在 user 表中指定。它不是管理权限，但用户在服务器主机上的读取或写入文件的能力独立于访问的数据库。

为了允许 MySQL 授权表的并发 DML 和 DDL 操作，读操作以前获取行锁的 MySQL 授权表现在执行为非锁定读取。这些操作包括：

语句不再获取行锁时读取授权表数据，将报告警告，如果使用语句基于复制。

使用 -binlog_format=mixed，DML 操作从授权表中读取数据将被写入二进制日志作为行事件，以使操作安全地用于混合模式复制。

SELECT ... FOR SHARE 语句从授权表中读取数据将报告警告。使用 FOR SHARE 子句，不支持在授权表上的读锁。

使用SERIALIZABLE隔离级别执行的读取授权表数据的DML操作将报告警告。在授权表上，不支持使用SERIALIZABLE隔离级别通常获取的读锁。