php - 在一个 API 请求中包含多个联接的单个查询，还是在单独的 API 请求中包含一些联接的几个查询？

Question

什么是最佳实践，什么提供最佳性能？

我目前有一个包含许多 LEFT JOIN 的查询，它获取一个 user 和他的所有数据，比如 friend 、 friend 请求等等:

SELECT
    `user`.`id` AS `user_id`,
    `user`.`name` AS `user_name`,
    `manager`.`id` AS `manager_id`,
    `competition`.`id` AS `manager_competition_id`,
    `competition`.`name` AS `manager_competition_name`,
    `competition`.`week` AS `manager_competition_week`,
    `country`.`id` AS `manager_competition_country_id`,
    `country`.`name` AS `manager_competition_country_name`,
    `club_template`.`id` AS `manager_club_template_id`,
    `club_template`.`name` AS `manager_club_template_name`,
    `club`.`id` AS `manager_club_id`,
    `club`.`name` AS `manager_club_name`,
    `club`.`ready` AS `manager_club_ready`,
    `friend`.`friend_id` AS `friend_id`,
    `friend_user`.`name` AS `friend_name`
FROM
    `users` AS `user`
LEFT JOIN
    `managers` AS `manager`
ON
    `manager`.`user_id` = `user`.`id`
LEFT JOIN
    `competitions` AS `competition`
ON
    `competition`.`id` = `manager`.`competition_id`
LEFT JOIN
    `countries` AS `country`
ON
    `country`.`id` = `competition`.`country_id`
LEFT JOIN
    `club_templates` AS `club_template`
ON
    `club_template`.`id` = `manager`.`club_template_id`
LEFT JOIN
    `clubs` AS `club`
ON
    `club`.`id` = `manager`.`club_id`
LEFT JOIN
    `friends` AS `friend`
ON
    `friend`.`user_id` = `user`.`id`
LEFT JOIN
    `users` AS `friend_user`
ON
    `friend_user`.`id` = `friend`.`friend_id`
WHERE
    `user`.`id` = 1

如您所见，这是一个非常大的查询。我的理由是，最好只有一个查询可以在一个 API 请求中完成，就像这样......

/api/users/1

...相对于一些查询，每个查询都有自己的 API 请求，就像这样...

/api/users/1
/api/users/1/friends
/api/users/1/friend_requests
/api/users/1/managers

但现在我很担心，因为它变成了一个如此庞大的查询，实际上它对性能的损害比将其拆分为单独的 API 请求还要严重。

什么会更好地扩展？

更新

我已将查询更改为完整查询。这不是最终查询；我计划添加更多连接(或不添加，取决于答案)。

每个表在 id 上都有一个 PRIMARY KEY。所有关联列(competition_id、club_id 等)都有一个常规的 INDEX。数据库引擎是InnoDB。

Answer 1

在这两者中，我会推荐后者:许多利基查询。它使调用者可以灵活地拉回他们想要的东西，并且不太可能悄悄地引入性能问题(例如，只有一个选项来检索数据，所以每个人都使用它，无论他们真正感兴趣的数据子集有多小).

也就是说，它当然不能免受性能问题的影响，这只是意味着调用者可能会通过发出如此多的 API 调用而更加意识到这些问题。

不过您可以同时提供两者。从您的命名约定中明确指出，昂贵的版本会拉回所有数据，并且在用户可能需要调用 20 - 30 次调用才能获得完整图片时使用。

例子:

1 - 想象一下必须获取完整的用户对象才能找出名称。真是浪费。如果在一个大循环中不经意地完成，性能陷阱等待发生。喜欢 getUserName(id)只读回那个值的方法。

2 - 另一方面，如果您想在页面中显示用户的完整个人资料，那么完整的 getFullUserProfile(id)是最有效的(1 次调用而不是 10 - 20 次)。

编辑 - 另一个有用的示例。预测在哪里寻找许多值，例如而不是强制调用者运行 getUserName(id) 500 次以获取特定条件下的所有名称(也许所有管理员用户？)，提供 List<String> getAdminUserNames()一次调用即可提供所有数据。