相对于队列深度n使用队列中的消息时，应用 JMS 选择器的算法时间复杂度是多少？特别是，每次读取是否线性 (O(n))？它是否依赖于实现(取决于 JMS 提供程序)，它是否取决于请求的字段？
(如果依赖于实现，我对 Websphere MQ 和 Solace 的行为特别感兴趣，但我欢迎处理任何特定 JMS 提供程序的答案，特别是如果您有描述复杂性的文档链接！
动机：每条消息都有两个属性：invocationID和batchName。批处理由多个调用组成。客户端希望以以下两种方式之一使用消息;要么通过invocationID，要么通过batchName.在生成消息时，我不知道它们将通过哪种方法使用。
这可以通过选择器实现：
invocationID=42
或
batchName="reconciliation"
。我可以通过使用相关 ID 而不是自定义属性来加快其中一个速度，但担心另一个会保持缓慢。
根据文档，邮件是按顺序搜索的。 但是，WMQ 会索引MessageID和CorrelID字段。 信息中心描述的行为如下：
从队列中选择消息需要 WebSphere MQ 按顺序 检查队列上的每条消息。检查消息，直到 找到与选择条件匹配的邮件或没有 要检查的更多消息。因此，如果出现以下情况，消息传递性能会受到影响 消息选择用于深层队列。
在基于选择时优化深度队列上的消息选择 在 JMSCorrelationID 或 JMSMessageID 上，使用 形式 JMSCorrelationID = ...或 JMSMessageID = ...仅供参考 一个属性。
此方法显著提高了 在JMSCorrelationID上进行选择并提供边际性能 JMSMessageID 的改进。
我很想更多地了解多路复用队列的要求。 复杂的选择器会影响任何人的实现性能，使用多个打开句柄和更简单的选择器的替代方法与使用多个队列与应用代码没有什么不同。 当然，对于 WMQ 来说，动态队列或许多永久定义的队列根本不是问题。 当我看到这个要求时，它经常来自使用某些其他运输工具的商店，这些商店的性能严重下降，定义了许多队列，并且有一个假设，即在WMQ上也是如此。 在其他情况下，发布/订阅和持久订阅已满足要求。 我并不是说这个要求没有有效的案例，只是想知道是什么推动了它。
这完全取决于实现。许多 JMS 提供程序将消息存储在 SQL 数据库中，以便它们可以使用 SQL 进行选择器实现。在这种情况下，您必须查看如何将您的特定案例映射到 SQL。
至于 WebSphereMQ - 选择器实现是 O(log n) 用于JMSMessageID = sth和JMSCorrelationID = sth，对于其他人我没有特定的知识。根据经验，它看起来像O(n)。
在 WebSphere MQ V7 中，选择器的实现发生了变化。使用 v7 JMS 客户端和 v7 QueueManager，选择处理在 QueueManager 端完成。 使用 v6 JMS 客户端(或者实际上是在其迁移模式下工作的 v7 客户端)模式，所有消息都将流向客户端进行处理。 如果匹配消息的命中率很低，就会浪费很多精力。所以
使用 v7 时，处理是在 QueueManager 端完成的，因此只有匹配的消息才会发送到客户端。
请记住，队列管理器不像数据库那样维护消息属性的复杂索引。因此，选择器越简单越好。