MySQL如何限制用户对INFORMATION_SCHEMA的访问并调整元数据权限？

MySQL 的 INFORMATION_SCHEMA 是数据库管理员和安全人员经常打交道的一个虚拟库，里面存放着数据库、表、列、索引、权限、连接等元数据。很多团队在处理账号安全时，第一反应是直接回收某个用户对 INFORMATION_SCHEMA 库的查询权限，执行类似 REVOKE SELECT ON INFORMATION_SCHEMA.* FROM 'user'@'host'; 的语句，结果往往收到 MySQL 的错误提示。这是因为 INFORMATION_SCHEMA 不是普通的业务库，它没有真实的授权对象，权限控制方式也完全不同。真正要限制用户对元数据的访问，需要从用户实际持有的库表权限、全局权限以及若干系统参数入手。

INFORMATION_SCHEMA 的权限模型与常见误区

INFORMATION_SCHEMA 本质上是一个只读的虚拟数据库，它不存储独立的数据文件，查询它时会动态访问 MySQL 的数据字典和内存中的状态信息。在 MySQL 8.0 中，数据字典已经统一迁移到 InnoDB 存储中，INFORMATION_SCHEMA 中的表大多以视图形式呈现，因此它的权限规则和其他数据库完全不同。

最典型的误区是管理员尝试直接对 INFORMATION_SCHEMA 执行授权或回收操作，实际上 MySQL 并不允许这样做。例如执行 GRANT SELECT ON INFORMATION_SCHEMA.* TO 'app_user'@'localhost'; 或 REVOKE SELECT ON INFORMATION_SCHEMA.* FROM 'app_user'@'localhost';，都会得到类似 Access denied for user 'root'@'localhost' to database 'information_schema' 的错误提示。也就是说，INFORMATION_SCHEMA 不能作为 GRANT 或 REVOKE 的目标对象。

用户在 INFORMATION_SCHEMA 中能看到的行数，取决于其对底层数据库对象的实际权限。例如，TABLES 和 COLUMNS 表只会返回用户拥有至少某种权限的库表信息；SCHEMATA 表的返回结果则受 SHOW DATABASES 权限和 skip_show_database 变量影响；PROCESSLIST 表需要 PROCESS 或 CONNECTION_ADMIN 权限才能查看其他用户的连接。因此，控制 INFORMATION_SCHEMA 访问的核心，是控制用户实际拥有的底层权限。

通过最小权限授权控制元数据可见性

最小权限原则是限制元数据泄露的第一道防线。创建数据库账号时，应只授予其完成业务所需的最小范围权限，而不是为了方便直接授予全局权限。全局权限如 SELECT ON *.*、SHOW DATABASES、PROCESS 会显著放大用户在 INFORMATION_SCHEMA 中的可见范围。

下面创建一个只拥有 webdb 库增删改查权限的账号，并观察其在元数据表中的表现。

CREATE USER 'web_app'@'localhost' IDENTIFIED BY 'Str0ngPass123!';
CREATE DATABASE webdb;
GRANT SELECT, INSERT, UPDATE, DELETE ON webdb.* TO 'web_app'@'localhost';
FLUSH PRIVILEGES;

使用 web_app 账号登录后，执行 SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES;，会发现结果中只包含 webdb 库及其表，而不会显示其他业务库的信息。再执行 SHOW DATABASES;，如果服务器未开启 skip_show_database，由于默认所有用户都能看到全部数据库名，仍然会列出服务器上的所有库名，但进入具体业务库查询表时会受到权限限制。这说明数据库名泄露和表级数据泄露是两个不同层面，需要分别处理。

如果用户被错误授予了 GRANT SELECT ON *.* TO 'web_app'@'localhost';，那么该用户查询 INFORMATION_SCHEMA.TABLES 就会看到所有库的所有表，即使它并不需要跨库访问。所以在日常授权时，应避免使用 *.* 形式，尤其是对业务账号和只读账号。

使用 skip_show_database 与 partial_revokes 进一步收缩可见范围

skip_show_database 是 MySQL 提供的一个全局变量，默认值为 OFF。当它关闭时，即使一个用户只对 webdb 库有权限，它执行 SHOW DATABASES; 仍然能看到服务器上所有的数据库名。这会造成数据库名的元数据泄露。开启该变量后，用户只能看到自己拥有权限的数据库，以及部分系统数据库如 information_schema 和 performance_schema 本身。

开启方式有两种。一种是在线执行 SET GLOBAL skip_show_database = ON;，但这种修改不会影响已经建立的连接，需要用户重新连接才会生效。另一种是在配置文件 my.cnf 或 my.ini 中的 [mysqld] 段加入 skip_show_database=ON，然后重启 MySQL 服务使其永久生效。配置完成后，受限用户再执行 SHOW DATABASES; 就只能看到有权限的数据库，INFORMATION_SCHEMA.SCHEMATA 的返回结果也会同步收缩。

对于 MySQL 8.0.16 及以上版本，还可以借助 partial_revokes 机制进一步细化权限控制。该变量默认关闭，开启后允许管理员对已经授予的全局权限按模式进行撤销。比如某个账号需要全局只读权限用于数据归档或报表查询，但不希望它读取 mysql 系统库中的权限表，可以这样操作。

SET PERSIST partial_revokes = ON;
CREATE USER 'read_user'@'%' IDENTIFIED BY 'ReadOnlyPass123!';
GRANT SELECT ON *.* TO 'read_user'@'%';
REVOKE SELECT ON mysql.* FROM 'read_user'@'%';
REVOKE SELECT ON performance_schema.* FROM 'read_user'@'%';

执行完成后，read_user 仍然拥有其他业务库的全局只读权限，但无法读取 mysql.user、mysql.db 等权限表，也就无法通过 INFORMATION_SCHEMA.USER_PRIVILEGES 或直接查询权限表来窥探更多账号信息。需要注意的是，不能直接对 INFORMATION_SCHEMA 使用 REVOKE，因为它本身不承载可授予的权限，只能通过回收底层对象权限间接控制。

通过视图封装元数据访问并完成验证

除了依赖系统权限之外，还可以使用 SQL 视图对元数据访问做一层封装。管理员可以在某个受控库中创建只读视图，只暴露必要的元数据字段和过滤条件，然后将该视图的查询权限授予用户。用户无需直接接触 INFORMATION_SCHEMA 表，也能获得完成工作所需的元数据信息。

例如，管理员想让 web_app 用户只能查看 webdb 库中所有表的基本信息，但不希望它访问其他库的元数据，可以创建如下视图。

CREATE VIEW webdb.v_my_tables AS
SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE, TABLE_ROWS
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = 'webdb';

GRANT SELECT ON webdb.v_my_tables TO 'web_app'@'localhost';

视图的 DEFINER 通常为创建者，默认以创建者权限执行，因此用户即使没有直接查询 INFORMATION_SCHEMA.TABLES 的完整权限，只要拥有视图的 SELECT 权限，就能看到视图定义中限定的数据。这种方式非常适合对外提供少量元数据查询能力的场景，也能有效避免过宽的元数据暴露。

完成上述配置后，建议使用受限账号实际登录验证。依次执行以下 SQL，确认可见范围符合预期：

SHOW DATABASES;
SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES;
SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST;
SHOW GRANTS FOR 'web_app'@'localhost';

如果发现 SHOW DATABASES; 仍然返回所有库名，应检查 skip_show_database 是否已经开启，并确认当前会话是新连接。如果发现 INFORMATION_SCHEMA.TABLES 返回了未授权库表，应检查用户是否被授予了多余的全局权限或业务库权限。最后，定期使用 SHOW GRANTS 审计账号权限，也是防止元数据权限被逐步放大的有效措施。

MySQLINFORMATION_SCHEMA权限控制修改时间：2026-10-05 10:36:25