必须显式逐库授予SELECT权限，否则跨库JOIN报ERROR 1142；需严格匹配用户主机名、用反引号包裹特殊库名，并通过角色批量管理但不可跳过单库授权步骤。

SELECT 权限必须显式授予每个参与跨库 JOIN 的数据库，否则直接报 ERROR 1142 (42000): SELECT command denied——这不是 BI 工具的问题，是 MySQL 权限校验机制本身决定的。

为什么 BI 工具跨库查询总失败？

BI 工具（如 Tableau、Metabase、Superset）执行 SELECT * FROM sales.orders JOIN customers.users 时，MySQL 不会检查“用户有没有跨库能力”，而是分别验证：

• 调用者是否有 sales.orders 的 SELECT 权限
• 调用者是否有 customers.users 的 SELECT 权限

两者缺一不可。哪怕只漏一个库、主机名写错（比如 'bi_user'@'localhost' vs 'bi_user'@'%'）、或库名含短横线但没加反引号（`my-db`），都会触发拒绝。

如何安全地授权给 BI 用户？

不能靠通配符“偷懒”，也不能建视图绕过——视图仍以调用者身份校验权限。正确做法是：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 为每个目标库单独执行 GRANT SELECT ON `sales`.* TO 'bi_user'@'192.168.1.%';
• 确保主机名完全一致：BI 服务 IP 必须匹配 'bi_user'@'192.168.1.%' 中的 host 段
• 库名含特殊字符（如 -、_、大小写混用）必须用反引号包裹，否则授权无效
• 避免使用 'bi_user'@'%'；生产环境应限定到 BI 服务器内网 IP 段

MySQL 8.0+ 角色能简化但不能跳过授权

角色只是把重复操作收口，不改变权限校验逻辑：

• 先创建角色：CREATE ROLE 'bi_reader';
• 再分别授权：GRANT SELECT ON `sales`.* TO 'bi_reader'; 和 GRANT SELECT ON `customers`.* TO 'bi_reader';
• 最后赋给用户：GRANT 'bi_reader' TO 'bi_user'@'192.168.1.50';
• 用户需主动启用：SET ROLE 'bi_reader';（或设为默认角色）

注意：FLUSH PRIVILEGES 在用 GRANT 修改后通常不需要；但如果直接改了 mysql.db 表才需要刷新。

容易被忽略的三个硬伤

很多团队卡在这三处，反复重试却查不出原因：

• SHOW GRANTS FOR 'bi_user'@'192.168.1.50'; 返回空？说明该用户+主机组合根本不存在，得先 CREATE USER
• BI 连接字符串里填的是 127.0.0.1，但你授的是 'bi_user'@'localhost'——这两者在 MySQL 中不等价，必须统一
• 用了 GRANT SELECT ON db%.* 却没加反引号，MySQL 把 db% 当作字面量库名去查，自然找不到匹配项