必须显式逐库授予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%当作字面量库名去查，自然找不到匹配项
