INNER JOIN会漏掉无权限资源，因只返回权限表中有匹配记录的行；须用LEFT JOIN以资源表为左表、权限表为右表，并在SELECT中用CASE WHEN判断up.permission_type IS NOT NULL来标记授权状态，避免WHERE过滤NULL行。
为什么直接用 INNER JOIN 会漏掉无权限的资源？
动态权限模型里，用户可能对某些资源没显式授权（即权限表里压根没这条记录），但业务常需“查出所有资源，并标记是否有权”。这时用 INNER JOIN 只返回有匹配权限的行，天然丢弃无权限项。必须改用 LEFT JOIN，把资源表作为左表，权限表作为右表，才能保全全部资源行。
常见错误是把权限表放左边、资源表放右边，结果变成“只查有权限的用户能看到哪些资源”，和需求反了。
- 资源表（如
resources）必须作FROM主表 - 权限表（如
user_permissions）跟在LEFT JOIN后，且ON条件里必须包含用户 ID 和资源 ID 两字段 -
WHERE里不能对右表字段加非空限制（比如WHERE up.permission = 'read'），否则会把NULL行过滤掉，等效于INNER JOIN
如何用 CASE WHEN 标记权限状态而不影响行数？
LEFT JOIN 后，权限字段为 NULL 表示无授权。直接 SELECT * 无法区分“禁止”和“未配置”，需要用 CASE WHEN 显式转义。关键是把判断逻辑写在 SELECT 列中，而不是 WHERE 或 ON 中。
示例：假设权限表有 user_id、resource_id、permission_type（值为 'read'、'write' 等）：
SELECT r.id, r.name, CASE WHEN up.permission_type IS NOT NULL THEN 'granted' ELSE 'denied' END AS access_status FROM resources r LEFT JOIN user_permissions up ON r.id = up.resource_id AND up.user_id = 123;
注意：up.permission_type IS NOT NULL 比 up.resource_id IS NOT NULL 更安全——避免因权限表存在脏数据（如 resource_id 为空）导致误判。
多角色叠加时，LEFT JOIN 还够用吗？
单用户单角色场景下，LEFT JOIN 加 CASE 足够。但若用户属于多个角色，权限来自角色表（roles）、角色-权限关联表（role_permissions）、用户-角色关联表（user_roles），就不能只连一张权限表了。
此时必须用子查询或 CTE 预聚合权限，否则 JOIN 会产生笛卡尔积：一个资源被多个角色授权，就重复出现多行。
- 推荐用
EXISTS替代多层JOIN：检查“是否存在任一角色对该资源有某权限” - 或用
GROUP BY r.id+MAX(CASE ...)在外层合并重复行 - 避免在
ON条件里连三张表（user_roles→role_permissions→resources），极易因中间表空数据导致整行丢失
性能陷阱：JOIN 字段没索引会导致全表扫描
权限表通常远大于资源表，而 LEFT JOIN 的效率极度依赖 ON 条件字段的索引。如果 user_permissions 表只对 id 建了主键，但 ON 用的是 (user_id, resource_id)，那每次 JOIN 都是全表扫。
必须确保组合索引覆盖实际 JOIN 和 WHERE 条件：
CREATE INDEX idx_user_resource ON user_permissions (user_id, resource_id);- 若还需按权限类型过滤，扩展为
(user_id, resource_id, permission_type) - 资源表的主键
id本身已是聚簇索引，一般不用额外建索引，但若常按name或type查询，得单独建
没索引时，10 万行权限数据 JOIN 1000 行资源，执行时间可能从毫秒级跳到秒级——这点容易被开发忽略，等上线后慢查询才暴露。
