【问题标题】:How to optimize this MySQL query? (CROSS JOIN, subquery)如何优化这个 MySQL 查询? (交叉连接,子查询)
【发布时间】:2015-03-18 17:19:31
【问题描述】:

我有一个对 MySQL 专家具有挑战性的问题。

我有一个包含 4 个表的用户权限系统:

  1. users (id | email | created_at)
  2. permissions (id | responsibility_id | key | weight)
  3. permission_user (id | permission_id | user_id)
  4. responsibilities (id | key | weight)

可以为用户分配任意数量的权限,并且可以将任意权限授予任意数量的用户(多对多)。职责就像权限组,每个权限只属于一个职责。例如,一个权限称为update,负责customers。另一个是delete,负责orders

我需要为每个用户获取完整的权限映射,但仅限于那些至少获得一项权限的用户。结果应按以下顺序排序:

  1. 用户的权限数量从多到少
  2. 用户的created_at 列,最早的在前
  3. 责任weight
  4. 权限weight

示例结果集:

user_id | responsibility | permission | granted
-----------------------------------------------
      5 | customers      | create     |       1
      5 | customers      | update     |       1
      5 | orders         | create     |       1
      5 | orders         | update     |       1
      2 | customers      | create     |       0
      2 | customers      | delete     |       0
      2 | orders         | create     |       1
      2 | orders         | update     |       0

假设我在数据库中有 10 个用户,但其中只有两个拥有任何权限。共有4个权限:

  1. createcustomers 责任
  2. updatecustomers 责任
  3. createorders 责任
  4. updateorders 责任。

这就是我们在结果中有 8 条记录的原因(2 个具有任意权限的用户 × 4 个权限)。首先显示 id = 5 的用户,因为他有更多权限。如果有任何抽签,日期较早的created_at 将先抽签。权限总是按其职责的权重排序,然后按其自身的权重排序。

我的问题是,如何为这种情况编写 最佳 查询?我自己已经做了一个,效果很好:

SELECT `users`.`id` AS `user_id`,
       `responsibilities`.`key` AS `responsibility`,
       `permissions`.`key` AS `permission`,
       !ISNULL(`permission_user`.`id`) AS `granted`
FROM `users`
CROSS JOIN `permissions`
JOIN `responsibilities`
  ON `responsibilities`.`id` = `permissions`.`responsibility_id`
LEFT JOIN `permission_user`
       ON `permission_user`.`user_id` = `users`.`id`
      AND `permission_user`.`permission_id` = `permissions`.`id`
WHERE (
    SELECT COUNT(*)
    FROM `permission_user`
    WHERE `user_id` = `users`.`id`
) > 0
ORDER BY (
             SELECT COUNT(*)
             FROM `permission_user`
             WHERE `user_id` = `users`.`id`
         ) DESC,
         `users`.`created_at` ASC,
         `responsibilities`.`weight` ASC,
         `permissions`.`weight` ASC

问题是我使用了两次相同的子查询。

我可以做得更好吗? MySQL 专家,我指望你!

--- 编辑 ---

感谢 Gordon Linoff 的评论,我使用了HAVING 子句:

SELECT `users`.`email`,
       `responsibilities`.`key`,
       `permissions`.`key`,
       !ISNULL(`permission_user`.`id`) as `granted`,
       (
           SELECT COUNT(*)
           FROM `permission_user`
           WHERE `user_id` = `users`.`id`
       ) AS `total_permissions`
FROM `users`
CROSS JOIN `permissions`
JOIN `responsibilities`
  ON `responsibilities`.`id` = `permissions`.`responsibility_id`
LEFT JOIN `permission_user`
       ON `permission_user`.`user_id` = `users`.`id`
      AND `permission_user`.`permission_id` = `permissions`.`id`
HAVING `total_permissions` > 0
ORDER BY `total_permissions` DESC,
         `users`.`created_at` ASC,
         `responsibilities`.`weight` ASC,
         `permissions`.`weight` ASC

我惊讶地发现HAVING 可以在没有GROUP BY 的情况下单独使用。

现在可以改进以获得更好的性能吗?

【问题讨论】:

  • 将子查询添加到select 子句。然后,您可以在 having 子句中使用别名进行过滤,也可以在 order by 中使用别名。
  • where 子句确保有 permission_user 行,即 LEFT JOIN 可以是常规 JOIN。
  • @jarlh 请仔细阅读我的问题。我说我需要显示所有权限,而不仅仅是那些被授予的权限。那里需要很多 NULL。
  • @GordonLinoff 就是这样!我从来不知道我可以在没有GROUP BY 的情况下使用HAVING
  • 当您需要检查至少一行是否存在时,最好使用 exists 而不是 select count

标签: mysql sql join subquery cross-join


【解决方案1】:

可能最有效的方法是:

SELECT u.email, r.`key`, r.`key`,
       !ISNULL(pu.id) as `granted`
FROM (SELECT u.*,
             (SELECT COUNT(*) FROM `permission_user` pu WHERE pu.user_id = u.id
       ) AS `total_permissions`
      FROM `users` u
     ) u CROSS JOIN
     permissions p JOIN 
     responsibilities r
     ON r.id = p.responsibility_id LEFT JOIN 
     permission_user pu
     ON pu.user_id = u.id AND
        pu.permission_id = p.id
WHERE u.total_permissions > 0
ORDER BY `total_permissions` DESC,
         `users`.`created_at` ASC,
         `responsibilities`.`weight` ASC,
         `permissions`.`weight` ASC;

这将为每个用户运行一次子查询,而不是每个用户/权限组合运行一次(正如修改后的查询和原始查询所做的那样)。这有两个成本。首先是子查询的物化,所以用户表中的数据必须重新读写。考虑到查询中的所有其他内容,可能没什么大不了的。第二个是users 表上的索引丢失。再一次,对于cross join,索引(可能)没有被使用,所以这也是次要的。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2020-05-10
    • 1970-01-01
    • 1970-01-01
    • 2015-05-19
    • 2014-09-08
    • 1970-01-01
    • 2010-11-15
    相关资源
    最近更新 更多