因第三方工具需查information_schema.columns等元数据，默认select权限不覆盖；须显式授权该视图及tables，设sql security definer视图，并禁用show databases与mysql.*访问。
为什么只给 SELECT 权限，第三方工具还是连不上？
因为多数报表或 BI 工具（如 Tableau、Power BI、Navicat 元数据探测）在连接后会自动查 INFORMATION_SCHEMA.COLUMNS、INFORMATION_SCHEMA.TABLES 甚至执行 SHOW CREATE TABLE——这些操作不归类于“表数据读取”，而属于“元数据访问”，默认不在 GRANT SELECT ON db_name.* 范围内。
现象通常是：能连上，但加载不到字段列表、报错 Access denied to database 'information_schema' 或直接卡在“正在获取表结构”。
解决思路不是开全局元数据权限，而是最小化授予必要视图：
-
GRANT SELECT ON INFORMATION_SCHEMA.COLUMNS TO 'reporter'@'192.168.10.%';（必须，几乎所有工具都依赖它） -
GRANT SELECT ON INFORMATION_SCHEMA.TABLES TO 'reporter'@'192.168.10.%';（可选，用于列出表名；若已限定具体表，可省略） - 不要授
INFORMATION_SCHEMA.*或mysql.*，否则暴露用户、权限、存储过程等敏感信息
视图依赖元数据时，权限怎么配才不翻车？
如果用视图统一口径（比如 project_x_vw_orders），而第三方工具通过视图查数据，那光有视图的 SELECT 权限还不够——MySQL 在运行视图时，会按 SQL SECURITY 设置检查底层基表权限。
常见错误是创建视图时没指定 SQL SECURITY DEFINER，导致执行时以调用者（即 reporter）身份去查基表，而 reporter 没有 project_x.orders 的 SELECT 权限，直接报错。
正确做法分两步：
- 建视图时显式声明：
CREATE SQL SECURITY DEFINER VIEW project_x_vw_orders AS ... - 确保视图所有基表（如
project_x.orders）对DEFINER用户（通常是 DBA）有完整SELECT权限，而 reporter 只需对视图本身有SELECT - 同时仍要授
INFORMATION_SCHEMA.COLUMNS，否则工具无法识别视图字段类型
host 和 authentication plugin 是两个高频断连点
很多情况下，你明明给了 SELECT 和 INFORMATION_SCHEMA.COLUMNS，但 Navicat 或 Python 的 pymysql 就是连不上。大概率卡在认证层，而非权限层。
检查这两项：
-
CREATE USER 'reporter'@'192.168.10.%' IDENTIFIED WITH mysql_native_password BY 'xxx';（MySQL 8.0+ 默认用caching_sha2_password，老客户端不认） - 确认报表服务器真实出口 IP 匹配
'reporter'@'192.168.10.%'；若走 NAT 或云厂商 LB，可能需要查SELECT SUBSTRING_INDEX(USER(), '@', -1);看实际匹配的 host 是什么 - 确保 MySQL 配置启用了
skip-name-resolve，否则反向 DNS 查询失败会导致连接超时或拒绝
权限生效后，记得关掉元数据泄露口
即使只读用户看不到其他库的数据，SHOW DATABASES 默认仍会列出所有库名（MySQL 5.7+ 行为）。更隐蔽的风险是：只要用户存在，就能查 mysql.db、mysql.user（如果误授了系统库权限）。
务必做三件事：
-
REVOKE SHOW DATABASES ON *.* FROM 'reporter'@'192.168.10.%';（隐藏非授权库名） -
REVOKE SELECT ON mysql.* FROM 'reporter'@'192.168.10.%';（防止查用户/权限表） - 避免给
GRANT OPTION——它允许用户把权限转授他人，哪怕只读也不行
最易被忽略的是 INFORMATION_SCHEMA.COLUMNS 授权后，工具能反推出表结构字段名和类型，这本身已是敏感信息。如果业务要求极严，应配合列级权限或应用层脱敏，不能只靠数据库权限兜底。
