在客户端而不是查询中按日期对 SQL 结果进行排序

Question

假设我有一些表格随着时间的推移跟踪用户的体重。

CREATE TABLE `userWeights` (
  `weight_id` int PRIMARY KEY AUTO_INCREMENT,
  `user_id` int,
  `weight` float,
  `date_created` timestamp
);

这里明显的用例是一些 REST 端点 getWeights(user_id)，然后在 UI 上将其显示为图形。 我要写的标准查询是这样的：

SELECT * FROM userWeights WHERE user_id=user_id ORDER BY date_created ASC

但是当我们按日期排序时，对于这个用例永远不会改变的业务逻辑，排序计算负载是否可以外包给客户端的设备，从而提高 SQL 查询的性能？ 对于我们存储 6 个月每日体重测量值的 1000 个用户表来说，这会不会是一个微不足道的改进？

SELECT * FROM userWeights WHERE user_id=user_id
results.sort(date_created, ASCENDING); //e.g. code on android device

编辑：我问是因为许多云功能/云数据库主机根据每次调用的计算时间收费。

Answer 1

通常，数据库服务器上的排序比客户端应用程序中的要快。

在您的两个场景中，数据库和客户端之间传递的数据量是相同的。 唯一的区别是排序的开销。

通常，我的建议是在更强大的系统上进行排序，更接近数据。 但是，如果您有充分的理由——成本考虑是一个很好的理由——并且在客户端进行排序符合您的应用程序性能要求，那么您绝对可以考虑在客户端进行处理。

Answer 2

数据客户端与服务器端的实际排序性能可以忽略不计 - 但通常更接近数据（在数据库服务器上执行）。

但是，在考虑将排序放在何处时，还需要考虑其他一些事项：

可维护性——如果你把逻辑放在客户端，那么你添加的任何新客户端也必须实现排序逻辑。 因此，如果您有 web 应用程序、iOS 应用程序和 Android 应用程序，则必须确保在所有三个应用程序中实现排序以获得一致的用户体验。 如果您想更改所有应用程序的排序，您现在必须记住在三个地方进行，而如果逻辑位于共享 API 或 DB 中，那么您可以在一个地方进行更改。
负担能力——就像你说的，云提供商可以对计算时间收费。 如果这是一个严重的问题，您可以移动排序客户端，但就像我之前所说的那样，未来的可维护性将受到影响，这将花费您开发人员的时间，从而在未来花费金钱。

我建议弄清楚导入可维护性对您和可负担性的影响，以及从长远来看，移动排序客户端是否真的有助于可负担性。

Answer 3

吻。

在查询中添加ORDER BY很简单，也很难搞砸。

向客户端添加排序需要更多的击键并且更容易出错。

此外，甚至可以不付钱就吃掉你的蛋糕：排序可以是“免费的”：

CREATE TABLE `userWeights` (
  `user_id` int,
  `weight` float,
  `date_created` timestamp,
  PRIMARY KEY(user_id, date_created)
);

您仍然需要SELECT上的ORDER BY子句，但请注意，它在服务器或客户端上都需要零努力。

您拥有表定义的方式，它必须扫描整个表以查找所请求的user_id的行； 这种变化也避免了这种情况。 此外，这节省了无用weight_id的空间。

我的建议有一个问题：你不能同时记录两个不同的重量。 （这似乎是一个甚至可以尝试的错误！）

节约成本...

语法问题： WHERE user_id=user_id -- 其中一个需要是传入的参数。否则，它相当于“TRUE”。