优化下一个和上一个元素的查询

因此，您有两个任务：

1. 构建排序的项目列表（具有不同 ORDER BY 的 SELECT）
2. 显示有关每个项目的详细信息（从数据库中选择详细信息，并可能进行缓存）。

问题是什么？

PS：如果有序列表可能太大，您只需要实现PAGER功能即可。可能有不同的实现，例如，您可能希望将“LIMIT 5”添加到查询中并提供“显示下一个 5”按钮。按下此按钮时，会添加“WHERE price < 0.89 LIMIT 5”等条件。

这是一个想法。当杂货店插入/更新新选件时，而不是在最终用户选择要查看的数据时，您可以将成本高昂的操作卸载到更新中。这似乎是处理排序数据的一种非动态方式，但它可能会提高速度。而且，正如我们所知，性能和其他编码因素之间总是需要权衡。

创建一个表，用于保存每个选件和每个排序选项的下一个和上一个。（或者，如果您始终有三个排序选项，则可以将其存储在 offer 表中 -- 查询速度是使数据库非规范化的一个很好的理由）

因此，您将拥有以下列：

• 排序类型（未排序、价格、类和价格描述）
• 产品/服务 ID
• 上一个 ID
• 下一个 ID

从数据库中查询产品/服务详细信息页的详细信息时，NextID 和 PrevID 将成为结果的一部分。因此，每个详情页面只需要一个查询。

每次插入、更新或删除选件时，都需要运行一个过程来验证排序类型表的完整性/准确性。

我不确定我是否理解正确，所以如果没有，请告诉我;)

假设给定是排序列表的查询和该列表中的当前偏移量，即我们有一个和一个 .$query$n

最小化查询的一个非常明显的解决方案是一次获取所有数据：

list($prev, $current, $next) = DB::q($query . ' LIMIT ?i, 3', $n - 1)->fetchAll(PDO::FETCH_NUM);

该语句按当前排序顺序从数据库中获取上一个、当前和下一个元素，并将相关信息放入相应的变量中。

但是由于这个解决方案太简单了，我想我误解了一些东西。

我也做过这个噩梦。您当前的方法似乎是最好的解决方案，即使对于 10k 项目的列表也是如此。在 http 会话中缓存列表视图的 ID，然后使用它来显示（针对当前用户个性化）上一个/下一个。这很有效，尤其是当有太多方法可以过滤和排序初始项目列表而不仅仅是 3 个时。
此外，通过存储整个 ID 列表，您可以显示增强可用性的文本。"you are at X out of Y"

顺便说一句，这也是JIRA所做的。

要直接回答您的问题，请执行以下操作：

• 是的，这是一个很好的做法，因为当您的筛选器/排序和项目类型更加复杂时，它可以在不增加任何代码复杂性的情况下进行扩展。我正在一个具有 250k 篇文章的生产系统中使用它，这些文章具有“无限”的过滤/排序变化。将可缓存的 ID 修剪到 1000 也是一种可能性，因为用户很可能永远不会点击上一个或下一个超过 500 次（他很可能会返回并优化搜索或分页）。
• 我不知道更好的方法。但是，如果排序受到限制，并且这是一个公共站点（没有 http 会话），那么我很可能会非规范化。
• 不知道。
• 是的，对缓存进行排序听起来不错。在我的项目中，我称之为“搜索结果上的上一个/下一个”或“搜索结果上的导航”。
• 不知道。

通常，我将索引中的数据非规范化。它们可能存储在同一行中，但我几乎总是检索我的结果 ID，然后对数据进行单独的访问。这使得缓存数据变得非常简单。在延迟低、带宽高的 PHP 中，这并不是那么重要，但是当您有一个高延迟、低带宽的应用程序时，这样的策略非常有用，例如 AJAX 网站，其中大部分网站都是用 JavaScript 呈现的。

我总是单独缓存结果列表和结果本身。如果有任何内容影响列表查询的结果，则会刷新列表结果的缓存。如果有任何影响结果本身，则会刷新这些特定结果。这允许我更新任何一个，而不必重新生成所有内容，从而实现有效的缓存。

由于我的结果列表很少更改，因此我会同时生成所有列表。这可能会使初始响应速度稍慢，但它简化了缓存刷新（所有列表都存储在单个缓存条目中）。

由于我缓存了整个列表，因此在不重新访问数据库的情况下查找相邻项是微不足道的。运气好的话，这些项目的数据也将被缓存。这在 JavaScript 中对数据进行排序时特别方便。如果我已经在客户端上缓存了副本，我可以立即调用。

要具体回答您的问题，请执行以下操作：

• 是的，提前找出邻居，或者客户接下来可能访问的任何信息，这是一个绝妙的主意，特别是如果现在成本很低，而重新计算的成本很高。然后，它只是在额外的预计算和存储与速度之间进行权衡。
• 在性能和简单性方面，避免将逻辑上不同的东西捆绑在一起。索引和数据是不同的，可能会在不同的时间进行更改（例如，添加新的基准面会影响索引，但不会影响现有数据），因此应单独访问。从单线程的角度来看，这可能效率略低，但每次将某些内容捆绑在一起时，都会失去缓存有效性和异时性（扩展的关键是异时性）。
• 提前获取数据的术语是预取。预取可以在访问时或后台进行，但在实际需要预取数据之前进行。预计算也是如此。这是现在成本、存储成本和在需要时获得的成本的权衡。
• “排序缓存”是一个恰当的名称。
• 我不知道。

此外，当您缓存内容时，请尽可能以最通用的级别缓存它们。有些内容可能是特定于用户的（例如搜索查询的结果），而其他内容可能与用户无关，例如浏览目录。两者都可以从缓存中受益。目录查询可能很频繁，每次都节省一点，搜索查询可能很昂贵，但几次节省很多。

有很多方法可以做到这一点，就像给众所周知的猫剥皮一样。所以这里有几个我的。

如果你的原始查询很昂贵，你说它是，那么创建一个表，可能是一个内存表，用你昂贵且很少运行的主查询的结果填充它。

然后，可以在每个视图上查询第二个表，排序就像设置适当的排序顺序一样简单。

根据需要，使用第一个表的结果重新填充第二个表，从而使数据保持最新，但最大限度地减少使用成本高昂的查询。

或者，如果你想避免连接到数据库，那么你可以将所有数据存储在一个 php 数组中，并使用 memcached 存储它。这将非常快，并且只要您的列表不是太大，就可以节省资源。并且可以轻松分类。

直流

基本假设：

• 特价是每周一次
• 我们可以预期网站不会经常更改......可能每天都有？
• 我们可以使用以太 API 控制对数据库的更新，也可以通过触发器进行响应

如果网站每天都在变化，我建议所有页面都是在一夜之间静态生成的。每个排序顺序的一个查询将循环访问并生成所有相关页面。即使存在动态元素，您也可以通过包含静态页面元素来解决它们。这将提供最佳的页面服务，并且没有数据库负载。事实上，您可以生成单独的页面和包含在页面中的上一个/下一个元素。这可能更疯狂，有 200 种排序方式，但有 3 种，我是它的忠实粉丝。

?sort=price
include(/sorts/$sort/tomatoes_class_1)
/*tomatoes_class_1 is probably a numeric id; sanitize your sort key... use numerics?*/

如果由于某种原因这不可行，我会求助于记忆。Memcache因这种事情而流行（双关语！当某些内容被推送到数据库时，您可以发出触发器以使用正确的值更新缓存。如果更新的项目存在于 3 个链表中，请以相同的方式执行此操作 - 根据需要重新链接（this.next.prev = this.prev 等）。从那时起，只要您的缓存不会过度填充，您就会以主键方式从内存中提取简单值。

此方法将在 select 和 update / insert 方法上进行一些额外的编码，但它应该相当少。最后，你会抬头看.如果该密钥位于缓存中，则为金色。如果没有，请插入缓存并显示。[id of tomatoes class 1].price.next

• 您认为这是找出不同查询订单的相邻记录的好做法吗？是的。明智的做法是对预期的即将到来的请求进行展望。
• 您知道在性能和简单性方面有更好的做法吗？你知道是什么让它完全过时了吗？希望以上
• 在编程理论中，这个问题有名字吗？优化？
• 对于这种技术，“排序缓存”这个名称是否合适且易于理解？我不确定具体的合适名称。它是缓存，它是某种缓存，但我不确定告诉我你有一个“排序缓存”是否会传达即时理解。
• 是否有任何公认的通用模式可以解决此问题？他们叫什么？缓存？

对不起，我的尾随答案有点没用，但我认为我的叙述解决方案应该非常有用。

您可以将有序列表的行号保存到视图中，并且可以在 （current_rownum-1） 和 （current_rownum+1） 行号下访问列表中的上一项和下一项。

问题/数据结构被命名为双向图，或者你可以说你有几个链表。

如果您将其视为链表，则可以将每个排序和上一个/下一个键的字段添加到项目表中。但是DB Person会为此杀了你，就像GOTO一样。

如果你把它想象成一个（双向）图，你会接受杰西卡的答案。主要问题是订单更新是昂贵的操作。

 Item Next Prev
   A   B     -
   B   C     A
   C   D     B
   ...

如果您将一个项目位置更改为新订单 A、C、B、D，则必须更新 4 行。

我的想法与杰西卡的想法有些相似。但是，您不是存储指向下一个和上一个排序项的链接，而是存储每种排序类型的排序顺序。若要查找上一条或下一条记录，只需获取 SortX=currentSort++ 或 SortX=currentSort 的行--.

例：

Type     Class Price Sort1  Sort2 Sort3
Lettuce  2     0.89  0      4     0
Tomatoes 1     1.50  1      0     4
Apples   1     1.10  2      2     2
Apples   2     0.95  3      3     1
Pears    1     1.25  4      1     3

此解决方案将产生非常短的查询时间，并且比 Jessica 的想法占用更少的磁盘空间。但是，我相信您已经意识到，更新一行数据的成本要高得多，因为您必须重新计算和存储所有排序顺序。但是，根据您的情况，如果数据更新很少，尤其是如果它们总是批量发生，那么此解决方案可能是最好的。

即

once_per_day
  add/delete/update all records
  recalculate sort orders

希望这是有用的。

如果我误解了，很抱歉，但我认为您希望在用户访问服务器之间保留有序列表。如果是这样，您的答案很可能在于您的缓存策略和技术，而不是数据库查询/模式优化。

我的方法是在首次检索数组后对其进行序列化（），然后将其缓存到单独的存储区域;无论是 memcached/APC/硬盘/mongoDb/ 等，并通过会话数据为每个用户单独保留其缓存位置详细信息。实际的存储后端自然取决于数组的大小，你不会详细介绍，但 memcached 可以在多个服务器和 mongo 上扩展得很好，延迟成本略高。

您也没有指出现实世界中有多少种排列;例如，您是否需要为每个用户缓存单独的列表，或者您可以全局缓存每个排序排列，然后通过PHP过滤掉不需要的内容？在您给出的示例中，我只需缓存这两种排列，并在会话数据中存储我需要 unserialize（） 的两种排列中的哪一种。

当用户返回到站点时，请检查缓存数据的“生存时间”值，如果仍然有效，请重新使用它。我还有一个在 INSERT/UPDATE/DELETE 上运行的触发器，用于特别优惠，只需在单独的表中设置时间戳字段。这将立即指示缓存是否过时，并且需要重新运行查询以非常低的查询成本。仅使用触发器设置单个字段的好处在于，无需担心从该表中删除旧/冗余值。

这是否合适取决于返回的数据的大小、修改数据的频率以及服务器上可用的缓存技术。