ERROR 1142报错主因是跨库权限缺失，须用SHOW GRANTS FOR CURRENT_USER;确认是否含GRANT SELECT ON db2.*，并逐库显式授权，不可依赖通配或隐式继承。
跨库JOIN前必须检查的权限错误
执行 SELECT ... FROM db1.t1 JOIN db2.t2 报 ERROR 1142 (42000): SELECT command denied to user，不是语法问题，而是权限缺失。MySQL不会提示“缺少db2权限”，错误里只写 table 't2'，容易误以为是表不存在或拼写错误。
真正要查的是：当前用户是否对 db2 有 SELECT 权限。用这条命令确认：
SHOW GRANTS FOR CURRENT_USER;
如果输出里没有类似 GRANT SELECT ON `db2`.* TO ... 的行，就说明缺权限。
- 权限必须显式授予，不能靠“连上db1就自动能读db2”
- 即使两个库在同一实例、同一连接，权限也按库隔离校验
-
FLUSH PRIVILEGES不是每次都要——只有直接改了mysql.user表才需要；用GRANT语句授完权可立即生效（MySQL 8.0+ 默认行为）
用GRANT语句精准扩展多库权限
不要用 GRANT ALL ON *.* 一步到位，那等于交出整台MySQL的控制权。安全做法是逐库、按需授权：
GRANT SELECT ON db1.* TO 'app_user'@'10.0.1.%';<br>GRANT SELECT ON db2.* TO 'app_user'@'10.0.1.%';<br>GRANT SELECT (id, name, email) ON db3.users TO 'app_user'@'10.0.1.%';
注意几个关键点：
- 数据库名带反引号（
`db-name-with-dash`），含特殊字符时必须包裹 - 列级权限（如最后一条）只适用于
SELECT，不支持INSERT/UPDATE的列限制 - 主机名尽量具体，避免用
'%'@'%'—— 生产环境应限定内网IP段或域名 - 如果后续还要写入
db2，再追加INSERT, UPDATE，而不是一开始就给全
视图和存储过程中跨库调用的权限陷阱
在视图里写 JOIN db1.users WITH db2.orders，看似只是查询，但实际执行时权限检查发生在**调用时刻**，不是定义时刻。默认 SQL SECURITY DEFINER 会用创建者的权限去查，这常被误用为“绕过权限检查”的手段。
更安全的做法是显式声明 SQL SECURITY INVOKER，让权限检查落到调用者身上：
CREATE VIEW user_order_summary AS<br>SELECT u.id, u.name, COUNT(o.id) cnt<br>FROM db1.users u<br>LEFT JOIN db2.orders o ON u.id = o.user_id<br>GROUP BY u.id, u.name<br>WITH CASCADED CHECK OPTION<br>SQL SECURITY INVOKER;
这样做的好处：
- 调用者必须同时拥有
db1.users和db2.orders的SELECT权限，否则SELECT * FROM user_order_summary直接报错 - 权限边界清晰，审计时能准确追溯到谁在什么权限下访问了哪些库
- 避免因视图创建者权限过高，导致低权限用户间接越权
权限扩展后最容易被忽略的验证点
授完权别急着写业务SQL，先做三件事：
- 用目标用户账号重新登录（
mysql -u app_user -p -h db-host），不要复用root或DBA会话——缓存可能让你误判权限已生效 - 执行
SELECT 1 FROM db2.t2 LIMIT 1单独测试目标库可读性，排除JOIN逻辑干扰 - 检查
information_schema.SCHEMA_PRIVILEGES表，确认db2确实出现在该用户权限记录中：SELECT * FROM information_schema.SCHEMA_PRIVILEGES WHERE GRANTEE = "'app_user'@'10.0.1.%'" AND TABLE_SCHEMA = 'db2';
跨库权限不是“开了就能用”，而是“开了+验证+持续监控”闭环。最危险的不是没授权，而是授权后没人验证它是否真生效、是否被意外覆盖。
