必须显式授予INFORMATION_SCHEMA.COLUMNS和TABLES的SELECT权限，并为视图设置SQL SECURITY DEFINER，同时使用mysql_native_password认证插件，否则BI工具无法加载字段或报Access denied。
第三方 BI 工具（如 Tableau、Power BI、Superset）连 MySQL 时卡在“加载字段”或报 Access denied to database 'information_schema'，不是账号密码错了，而是权限配得不完整——只给 SELECT 权限根本不够用。
为什么只授 SELECT ON db_name.* 还是连不上元数据？
BI 工具启动后第一件事不是查业务表，而是扫 INFORMATION_SCHEMA.COLUMNS 和 INFORMATION_SCHEMA.TABLES 来构建字段树和表列表。这些视图不属于任何业务库，也不受 GRANT SELECT ON your_db.* 覆盖。
- 必须显式授权：
GRANT SELECT ON INFORMATION_SCHEMA.COLUMNS TO 'bi_user'@'192.168.10.%'; - 如果工具还要列出所有表名（比如左侧数据库导航栏），加一句：
GRANT SELECT ON INFORMATION_SCHEMA.TABLES TO 'bi_user'@'192.168.10.%'; - 绝对不要写
GRANT SELECT ON INFORMATION_SCHEMA.*——会暴露SCHEMATA、ROUTINES等敏感元数据 - 执行完记得
FLUSH PRIVILEGES;，否则权限不生效
用视图统一口径时，SQL SECURITY DEFINER 必须设
如果你把业务逻辑封装进视图（比如 vw_sales_summary），而 BI 工具直接查这个视图，光有视图的 SELECT 权限还不够。MySQL 默认按调用者身份检查底层表权限，而 bi_user 并没有访问原始表（如 sales_fact）的权限，就会报错 SELECT command denied。
- 建视图时必须声明：
CREATE SQL SECURITY DEFINER VIEW vw_sales_summary AS ... -
DEFINER用户（通常是 DBA）需对底层所有基表有SELECT权限 -
bi_user只需对视图本身有SELECT权限 + 上面提到的INFORMATION_SCHEMA.COLUMNS - 验证方法：用
bi_user登录后执行DESCRIBE vw_sales_summary;，能出字段列表才算通
MySQL 8.0+ 的 caching_sha2_password 会让老客户端直接断连
很多 BI 工具（尤其是旧版 Navicat、某些 Python 驱动）不支持 MySQL 8.0 默认的 caching_sha2_password 插件，连接时静默失败，错误日志里可能只显示 “Access denied”，实际是认证协议不匹配。
- 创建账号时强制指定旧插件：
CREATE USER 'bi_user'@'192.168.10.%' IDENTIFIED WITH mysql_native_password BY 'xxx'; - 已有账号可改：
ALTER USER 'bi_user'@'192.168.10.%' IDENTIFIED WITH mysql_native_password BY 'xxx'; - 确认 host 匹配：若 BI 服务器走云厂商 LB 或 NAT，真实源 IP 可能不是你预设的
192.168.10.%，要用SELECT USER(), CURRENT_USER();在连接后查实际匹配的账号
别漏掉连接数限制和密码策略
长期运行的 BI 工具账号容易被遗忘，变成永久后门。生产环境必须加硬性约束：
- 限制最大并发连接：
ALTER USER 'bi_user'@'192.168.10.%' WITH MAX_CONNECTIONS_PER_HOUR 100; - 设置密码过期：
ALTER USER 'bi_user'@'192.168.10.%' PASSWORD EXPIRE INTERVAL 90 DAY; - 禁用
mysql、performance_schema、sys库的任何访问，哪怕只读——BI 工具不需要看这些
最常被忽略的是 INFORMATION_SCHEMA.COLUMNS 授权和 SQL SECURITY DEFINER 的组合；少一个，BI 工具就只能连上但看不到字段，排查时容易绕远路去调驱动或网络。
