真正要拦的是元数据查询路径而非DESCRIBE命令本身，因该命令依赖INFORMATION_SCHEMA表；MySQL 5.7及更早版本中，任意SELECT权限即隐式允许访问系统表，8.0+需显式回收系统表权限才能阻断。
不能靠“禁用 DESCRIBE”来防止——这个命令本身没有独立权限，它是否能执行，完全取决于用户能否访问 INFORMATION_SCHEMA.COLUMNS 等系统表。真正要拦的不是命令，而是元数据查询路径。
为什么给SELECT权限就等于能DESCRIBE
执行 DESCRIBE users 时，MySQL 内部会去查 INFORMATION_SCHEMA.COLUMNS 和 INFORMATION_SCHEMA.STATISTICS。只要用户对业务库有 SELECT 权限（哪怕只针对一张表），MySQL 5.7 及更早版本就会隐式允许其读取这些系统表——这是历史兼容行为，无法关闭。
- 即使你只执行了
GRANT SELECT ON appdb.users TO 'dev'@'%'，用户也能DESCRIBE appdb.users -
SHOW CREATE TABLE同理，依赖INFORMATION_SCHEMA.TABLES和表定义存储 - MySQL 8.0+ 虽支持细粒度授权，但默认仍沿用旧逻辑；只有显式收回系统表权限才生效
MySQL 8.0+ 的最小拦截方案
在 8.0.26+ 环境下，可精准阻断元数据访问，而不影响业务查询：
- 先确认用户没被意外授予全局或库级
SELECT：SHOW GRANTS FOR 'dev'@'%'，若输出含ON *.*或ON appdb.*，必须REVOKE SELECT ON *.* FROM 'dev'@'%'和REVOKE SELECT ON appdb.* FROM 'dev'@'%' - 只授业务所需的表级
SELECT：GRANT SELECT ON appdb.orders TO 'dev'@'%'（注意：必须带库名） - 显式拒绝系统表访问：
REVOKE SELECT ON INFORMATION_SCHEMA.COLUMNS FROM 'dev'@'%'、REVOKE SELECT ON INFORMATION_SCHEMA.TABLES FROM 'dev'@'%' - 执行
FLUSH PRIVILEGES，并让应用重连（旧连接缓存权限）
此时 DESCRIBE orders 会报错 ERROR 1142 (42000): SELECT command denied to user ... for table 'COLUMNS'。
MySQL 5.7 及更早版本的现实约束
这类版本不支持对 INFORMATION_SCHEMA 单独授权或回收，只要用户有任意 SELECT 权限，就能查结构。唯一可行路径是：
- 彻底不用
SELECT权限，改用视图封装 +SHOW VIEW授权（但需确保已REVOKE SELECT ON appdb.users） - 或启用
--skip-show-databases并配合应用层 SQL 代理，在语句进入 MySQL 前拦截DESCRIBE、SHOW COLUMNS等关键词 - 网络层限制：数据库仅允许应用服务器 IP 访问，且应用层禁止透传元数据查询请求
别指望 sql_mode 或错误信息脱敏能挡住 DESCRIBE——它不依赖错误反馈，而是直接走系统表查询。
最容易被忽略的绕过点
权限控制再严，也挡不住三类隐性暴露：
- 用户若有
SHOW VIEW权限，且存在基于目标表的视图，执行SHOW CREATE VIEW v_orders就能反推出字段名和类型 - 应用日志若记录了完整 SQL（如
SELECT id, name FROM users WHERE ...），字段名直接泄露 - 客户端工具（如 DBeaver、Navicat）在连接后自动执行
SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'appdb'，这类请求不会触发DESCRIBE但效果等价
真正安全的边界不在命令层，而在连接来源、SQL 生命周期管控和系统表访问链路的彻底切断。
