我有一个 Postgres 数据库，其中包含有关服务器集群的详细信息，例如服务器状态（“活动”、“待机”等）。活动服务器在任何时候都可能需要故障转移到备用服务器，我不在乎特别使用哪个备用服务器。
我想要一个数据库查询来更改备用服务器的状态 - 只有一个 - 并返回要使用的服务器 IP。选择可以是任意的：因为服务器的状态随着查询而改变，所以选择哪个备用数据库并不重要。
是否可以将我的查询限制为一次更新？
这是我到目前为止所拥有的：
UPDATE server_info SET status = 'active'
WHERE status = 'standby' [[LIMIT 1???]]
RETURNING server_ip;
Postgres 不喜欢这样。我可以做些什么不同的事情？
Postgres 是否有任何功能来支持老化的旧记录？
我想使用 Postgres 进行日志记录，作为一种队列，其中超过两周的记录（日志事件）会被自动删除。
有什么方法可以使用 Postgres 的监听/通知功能将消息传递到频道，并且只有一个监听器使用该消息？
这样做的目的是我有多个“工人”应用程序都在收听同一个 Postgres 频道。但我只希望通过通知渠道收到的每条消息完成一次工作。
如果侦听/通知不是 Postgres 中的正确功能，我应该使用单独的功能吗？
理想情况下，我希望在不使用任何其他扩展的情况下执行此操作。
I was attempting to answer the following stackoverflow question:
After posting a somewhat naive answer, I figured I'd put my money where my mouth was and actually test the scenario I was suggesting, to be sure I wasn't sending the OP off on a wild goose chase. Well, it's turned out to be much harder than I thought (no surprise there …
我在 MySQL 中有一个表，表示要处理的链接队列。链接由外部应用程序一一处理，最后删除。这是一个大容量队列，我有处理应用程序的多个实例，分布在多个服务器上。
如何确保每条记录仅由一个应用程序选取？有没有办法标记/锁定记录？
现在，为了避免两个或多个获取相同的链接，我只允许每个实例获取一组特定的记录（基于其 ID 的 MOD），但这不是增加队列处理的透明方式只需添加新实例即可加快速度。
我有一个服务代理应用程序，目前在两台服务器上有 5 或 6 个队列。
一般工作流程是：
服务器A
服务器B
服务器A
我曾建议将其中一些队列合并到服务器 A 上，但我不确定最佳做法是什么。其中两个队列的消息处理量相对较高，而电子邮件队列的速度会非常慢。
我们在管理消息类型方面做得（我认为）做得很好，因此理论上我们可以将它们全部放入一个队列中，并且应用程序仍然可以运行。
是否有关于何时维护单独队列以及何时在这种情况下合并的最佳实践？
我正在尝试设置查询通知，但是当我尝试创建队列和服务时，我收到错误消息“数据库中没有活动的 Service Broker。更改为包含 Service Broker 的数据库上下文。当我运行查询时
select is_broker_enabled from sys.databases where name='db01'
它返回 1 表示已在数据库上启用代理
这是我正在运行以创建队列和服务的 sql 命令...
CREATE QUEUE DeviceChangeMessages
CREATE SERVICE DeviceChangeNotifications ON QUEUE DeviceChangeMessages ([http://schemas.microsoft.com/SQL/Notifications/PostQueryNotification]);
我有一个需要执行的命令列表，所有这些命令都包含在我命名为 的表中myQueue。这个表有点独特，因为一些命令应该组合在一起，以便它们的执行按顺序执行，而不是并发执行，因为同时执行它们会导致不需要的数据工件和错误。因此，队列不能以典型的FIFO / LIFO方式分类，因为出队顺序是在运行时确定的。
总结一下：
myQueue将充当命令队列（其中出队顺序在运行时确定）UPDATE而不是 a执行的，DELETE因为此表用于所述命令的历史性能报告我目前的方法是通过sp_getapplock/sp_releaseapplock调用使用显式互斥逻辑来迭代这个表。虽然这按预期工作，但该方法会生成足够的锁定，因此在任何给定时间都无法在队列上迭代大量工作线程。在阅读了 Remus Rusanu关于该主题的优秀博客文章后，我决定尝试使用表格提示，希望可以进一步优化我的方法。
我将包含下面的测试代码，但总结一下我的结果，使用表提示和消除对sp_getapplock/ 的调用的缺点sp_releaseapplock最多会导致以下三种不良行为：
不过，从积极的方面来说，当代码适应死锁时（例如，重试当前包含的违规操作），不使用sp_getapplock/sp_releaseapplock且不会表现出不良行为的方法 2 和 3 的执行速度至少是两倍，如果不是更快的话.
我希望有人会指出我没有正确构建出列语句，这样我仍然可以继续使用表提示。 如果那不起作用，那就这样吧，但我想看看它是否可以做到同样的事情。
可以使用以下代码设置测试。
该myQueue表的创建和人口与命令类似于够我的工作量：
CREATE TABLE myQueue
(
ID INT IDENTITY (1,1) PRIMARY KEY CLUSTERED,
Main INT, …我正在寻找一种可以限制同时运行的作业数量的设置（除了计划转移）。我的 SQL 代理（SQL Server 2017 Enterprise）中有 844 个作业。他们中的大多数需要几分钟才能完成，大约有 190 个工作需要半小时。所有这些都计划每小时运行一次。如果它们一起运行，我无法将总持续时间控制在 60 分钟以下。是否有任何设置可以将 744 个作业排队，直到 844 个作业中的一个完成并且 SQL 代理将启动在队列中等待的下一个作业？
我们有一个看起来像这样的工作表
CREATE TABLE [dbo].[Clearing](
[Skey] [decimal](19, 0) IDENTITY(1,1) NOT NULL,
[BsAcctId] [int] NULL,
[Status] [varchar](20) NULL,
CONSTRAINT [csPk_Clearing] PRIMARY KEY CLUSTERED ( [Skey] ASC )
)
像这样的覆盖索引
CREATE NONCLUSTERED INDEX [IX_Status] ON [dbo].[Clearing]
(
[Status] ASC
)
INCLUDE ( [Skey], [BsAcctId])
我们使用这个查询来选择下一个工作
select top (1) Skey, BsAcctId, Status from Clearing with ( readpast, updlock )
where (Clearing.Status = 'NEW')
order by Clearing.Skey
（真实表大约有 10 列。它们都在索引 include() 子句和选择列列表中。）
执行计划非常简单。它使用 IX_Status 进行索引查找，然后使用顶级运算符。由于索引按 (status, skey) 排序，因此计划不需要排序。
该表位于 AlwaysOn 可用性组中的数据库中。该组有 2 个数据库服务器。（这是一个测试系统。）
通常这个表和查询工作得很好。所以我们去应用 Windows …
我有一个 PostgreSQL 表设置作为队列/事件源。
我非常希望保留事件的“顺序”（即使在处理队列项之后）作为 e2e 测试的来源。
我开始遇到查询性能下降的问题（可能是因为表膨胀），并且我不知道如何有效地查询不断变化的键上的表。
Postgres：v15
CREATE TABLE eventsource.events (
id serial4 NOT NULL,
message jsonb NOT NULL,
status varchar(50) NOT NULL,
createdOn timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
CONSTRAINT events_pkey PRIMARY KEY (id)
);
CREATE INDEX ON eventsource.events (createdOn)
BEGIN; -- Start transaction
SELECT message, status
FROM eventsource.events ee
WHERE status = 'PENDING'
ORDER BY ee.createdOn ASC
FOR UPDATE SKIP LOCKED
LIMIT 10; -- Get the OLDEST 10 events that are pending
-- I …我在 SQL Server 2012 中有一个简单的表，它实现了一个处理队列。随着数据的插入，检索下一个项目的查询从 <100 毫秒变为恒定的 5-6 秒。如果有人能指出性能突然下降的原因，我将不胜感激。（这似乎几乎是一夜之间的下跌）。
这是表定义：
CREATE TABLE [dbo].[messagequeue] (
[id] INT IDENTITY (1, 1) NOT NULL,
[testrunident] VARCHAR (255) NOT NULL,
[filesequence] INT NOT NULL,
[processed] BIT NOT NULL,
[dateentered] DATETIME NULL,
[filedata] VARBINARY (MAX) NULL,
[retries] INT NOT NULL,
[failed] BIT NOT NULL,
[msgobject] VARBINARY (MAX) NULL,
[errortext] VARCHAR (MAX) NULL,
[sourcefilename] VARCHAR (MAX) NULL,
[xmlsource] VARCHAR (MAX) NULL,
[messagetype] VARCHAR (255) NULL
);
CREATE NONCLUSTERED INDEX [messagequeue_sequenc_failed_idx]
ON [dbo].[messagequeue]([processed] ASC, [failed] ASC)
INCLUDE([id], …performance sql-server sql-server-2012 queue query-performance
queue ×12
sql-server ×7
postgresql ×4
concurrency ×3
locking ×2
delete ×1
event ×1
index ×1
mysql ×1
performance ×1
update ×1