以下 mysql 数据库表包含授权信息：

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

在 MySQL 8.4 中，授权表使用 InnoDB 存储引擎，并且是事务性的。在 MySQL 8.4 之前，授权表使用 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';

服务器在访问控制的第一阶段和第二阶段都使用 mysql 数据库中的 user 和 db 表（请参见 第 8.2 节“访问控制和帐户管理”）。user 和 db 表中的列如下所示。

user 表的 plugin 和 authentication_string 列存储身份验证插件和凭据信息。

服务器使用帐户行 plugin 列中命名的插件来验证该帐户的连接尝试。

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 语句。

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

password_last_changed 是一个 TIMESTAMP 列，指示上次更改密码的时间。该值仅对使用 MySQL 内置身份验证插件（已弃用的 mysql_native_password、已弃用的 sha256_password 或 caching_sha2_password）的帐户才为非 NULL。对于其他帐户（例如使用外部身份验证系统进行身份验证的帐户），该值为 NULL。

password_last_changed 由 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 表公开这些属性。

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 能够对帐户密码历史记录长度和重用间隔执行检查。当发生密码更改尝试时，将自动删除超出这两个限制的条目。

如果帐户被重命名，则其条目也会被重命名以匹配。如果删除了帐户或更改了其身份验证插件，则会删除其条目。

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

Host 和 Proxied_host 值在存储到授权表之前会转换为小写。

出于访问检查目的，User、Proxied_user、authentication_string、Db 和 Table_name 值的比较区分大小写。Host、Proxied_host、Column_name 和 Routine_name 值的比较不区分大小写。

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 授权表上获取行锁的读取操作将作为非锁定读取执行。在 MySQL 授权表上作为非锁定读取执行的操作包括：

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

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

从授权表读取数据的 SELECT ... FOR SHARE 语句会报告警告。对于 FOR SHARE 子句，授权表不支持读取锁。

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