如何通过MySQL系统表information_schema校验权限完整性？-mysql教程-PHP中文网

查 information_schema.user_privileges 可验证全局权限是否加载成功，若 count(*) 为 0，说明权限元数据损坏或系统库未正确迁移，应优先检查 mysql.user 表及执行 mysqld --upgrade=force。

如何通过mysql系统表information_schema校验权限完整性？

升级或重装 MySQL 后，USER_PRIVILEGES 表可能为空或字段值异常（如 PRIVILEGE_TYPE 为 NULL），说明权限系统未初始化完成。这不是业务数据问题，但会导致后续所有基于 INFORMATION_SCHEMA 的权限校验失效。

执行：

SELECT COUNT(*) FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE GRANTEE = CURRENT_USER();

若返回 0，即使能连上库，也大概率是权限元数据损坏或 mysql 系统库未正确迁移。此时应优先检查 mysql.user 表是否可读、mysqld --upgrade=FORCE 是否已执行，而不是直接排查应用连接配置。

SCHEMA_PRIVILEGES 是验证“用户对某库是否有 SELECT/INSERT 权限”的最直接依据，但它不反映动态权限（如 8.0+ 的 APPLICATION_PASSWORD_ADMIN）或角色继承关系。

常见误判点：

查询时必须写全 GRANTEE 格式，例如 'app_user@192.168.1.%'，不能只写用户名；
结果中 IS_GRANTABLE 为 NO 不代表没权限，只是不能转授；
如果目标库名含下划线或特殊字符，TABLE_SCHEMA 字段需用反引号包裹再比对，否则 LIKE 匹配会漏掉；
跨版本升级后，该表的 PRIVILEGE_TYPE 可能从 SELECT 变成 SELECT,LOCK TABLES（合并显示），需做字符串包含判断而非完全相等。

想验证“用户能否查某张业务表”，很多人直接查 TABLE_PRIVILEGES，但这个表本身需要用户有对 information_schema 的 SELECT 权限——形成循环依赖。更可靠的做法是：先用最小化查询试探权限，再查系统表佐证。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

推荐组合验证：

第一步：执行 SELECT 1 FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'your_table' LIMIT 1；
第二步：若成功，再查 TABLE_PRIVILEGES 确认具体权限项；
若第一步报错 ERROR 1142 (42000): SELECT command denied，说明连元数据都不可见，TABLE_PRIVILEGES 就不必查了；
注意：MySQL 8.0.23+ 对 TABLE_PRIVILEGES 增加了列级权限字段 COLUMN_NAME，旧版代码若未兼容该字段，SELECT * 可能因列数不匹配抛出异常。

很多校验只关注 DML 权限，却忽略 DDL 相关元数据访问能力。比如用户有 SELECT 权限，但查不到外键定义，就无法在应用层做关联预检或生成 ER 图。

关键检查逻辑：

执行 SELECT CONSTRAINT_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA = 'db' AND TABLE_NAME = 't1'，若返回空但实际存在外键，说明用户缺少对 KEY_COLUMN_USAGE 的访问权（常见于只授予 SELECT 但未显式给 INFORMATION_SCHEMA 权限）；
TABLE_CONSTRAINTS.CONSTRAINT_TYPE 值为 FOREIGN KEY 时，UPDATE_RULE/DELETE_RULE 字段在 5.7 和 8.0 中默认值不同（RESTRICT vs NO ACTION），若校验脚本硬编码比对，会误报不一致；
这两个表在 MySQL 8.0.30+ 开始支持隐藏列（如 _tidb_rowid），但普通账号默认查不到，需额外授权 SELECT on INFORMATION_SCHEMA 才能完整呈现。