标签: update

将 BIGSERIAL 列添加到大表（约 3 Bil. 行，约 174Gb）的最快方法是什么？

编辑：

• 我希望该列是现有行 ( NOT NULL) 的递增值。
• 我没有设置填充因子（回想起来，这似乎是一个错误的决定）。
• 我对磁盘空间没有问题，只是希望它尽可能快。

我想这样做：

DECLARE @Id INT;

UPDATE Logins
SET    SomeField = 'some value'
OUTPUT @Id = Id
WHERE  EmailAddress = @EmailAddress -- this is a parameter of the sproc

这甚至可能吗？我知道我可以声明一个本地表变量并将输出定向到那里，但如果可能的话我宁愿跳过它

我试图了解如何使用不同的值更新多行，但我不明白。解决方案无处不在，但对我来说似乎很难理解。

例如，两个更新为 1 个查询：

UPDATE mytable SET fruit='orange', drink='water', food='pizza' WHERE id=1;

UPDATE mytable SET fruit='strawberry', drink='wine', food='fish' WHERE id=2;

我不明白 CASE WHEN .. THEN ... END 的作用以及如何使用它。

想知道是否有人可以帮助我。

我有一个大约有一百万行的表。

它正在生产中使用，我运行了一个UPDATE覆盖了大约 95% 的行。

之后5小时我取消了请求，因为它正在采取这么长时间。

该表有一个自动递增的 ID 列，因此我尝试将WHERE查询条件扩展为包含id BETWEEN 1 AND 500.

此更新在大约两秒钟内完成。然后我手动迭代了id500 个批次，例如BETWEEN 500 AND 1000， then BETWEEN 1000 AND 1500。

按照这个速度，更新整个表需要 2000 个批次，每批次 500 个。

每 2 秒更新 2000 个批次只需一个多小时。

我的问题是：

1. 造成这种差异的原因是什么？
2. 我不关心事务隔离，所以有没有办法模拟这种“批量更新”，而不必编写 2000 个更新的脚本来单独运行。

我是一名“偶然”的 DBA，相对缺乏经验并且对这个问题感到困惑。

运行 MS SQL Server 2012。问题在于这个 UPDATE 语句：

UPDATE dbo.tAccts SET
       Ticket               = 'ARP.ExGE'
       , Method             = 'smtp'
       , AcctOwner          = 'r00417819'
       , DisplayName = '~AppLight HBSFax-Inactive'
       , Destination = 'r00417819@mail.ad.ge.com'
       , UpdatedBy          = SYSTEM_USER
       , UpdatedOn          = CAST(GetDate() AS DATE)
FROM dbo.vReclaimable
WHERE OHR_EmpStatus <> 'A'

这应该只更新tAccts 表中由 vReclaimable 视图返回的行。

vReclaimable 视图基于 tAccts 表并返回 tAccts 中行的子集。

当我运行它时，它失败并显示唯一键错误：

(0 row(s) affected)
Msg 2627, Level 14, State 1, Line 67
Violation of UNIQUE KEY constraint 'UQ__tAccounts_DNIS.Method.Destination.Phones'. Cannot …

我正在运行这样的并发 Postgres 查询：

UPDATE foo SET bar = bar + 1 WHERE baz = 1234

每个查询都会影响固定的 K 行数，我找不到强制执行更新行顺序的方法，最终导致死锁。目前我通过手动执行订单来解决这个问题，但这意味着我必须执行比平时更多的查询，同时还将搜索复杂度从 O(log N + K) 提高到 O(K log N)。

有没有办法提高性能而不会最终容易陷入死锁？我怀疑如果Postgres 以扫描它们的相同顺序更新行，用(baz)索引替换(baz, id)索引可能会起作用，这是一种值得追求的方法吗？

我编写了一个 SQL Server 查询，它在对字段进行分区后更新记录以具有序列号。当我将它作为 SELECT 语句运行时，一切看起来都很棒：

DECLARE @RunDetailID INT = 448
DECLARE @JobDetailID INT

SELECT @JobDetailID = [JobDetailID] FROM [RunDetails] WHERE [RunDetailID] = @RunDetailID

SELECT
    [OrderedRecords].[NewSeq9],
    RIGHT([OrderedRecords].[NewSeq9], 4)
FROM
    (
        SELECT
            [Records].*,
            [Records].[SortField] + RIGHT('0000' + CAST(ROW_NUMBER() OVER(PARTITION BY [Records].[SortField] ORDER BY [Records].[RunDetailID], [Records].[SortField], [Records].[PieceID]) AS VARCHAR), 4) NewSeq9
        FROM
        (
            SELECT
                [MRDFStorageID], 
                [RunDetailID], 
                [SortField], 
                [PieceID], 
                [Seq9], 
                [BallotType]
            FROM
                [MRDFStorage]
                    JOIN [BallotStyles] ON [MRDFStorage].[SortField] = [BallotStyles].[Style] and [BallotStyles].[JobDetailID] = @JobDetailID
            WHERE
                [RunDetailID] IN (SELECT [RunDetailID] FROM [RunDetails] WHERE [JobDetailID] = …

我想弄清楚为什么一个UPDATE语句需要太长时间（> 30 秒）。

这是随机的，即在大多数情况下，它在 100 毫秒内完成。但是，有时（随机）需要> 30 秒才能完成。

一些细节：

• 我使用的是 PostgreSQL 12（实际上是 AWS Aurora）
• 我正在一个没有流量的数据库中尝试这个，所以它不会受到同时运行的任何其他查询的影响。我也在监视日志以查看是否还有其他内容正在运行，但我什么也没看到。
• 我试过REINDEXing、VACUUMing（和VACUUM ANALYZE），但没有任何改进
• 我检查了锁，( log_lock_waits) 但我什么也没看到。
• 查询在循环中执行（来自 Python 应用程序）。它执行大约 5000 次查询，在某些时候，其中一些查询似乎没有遵循某种模式，需要花费大量时间才能完成。
• 我试过分批运行它们，但同样，有些批次随机运行时间太长。
• 表的大小有点大，约 10000000 行和约 25 个索引。

查询：

UPDATE "my_table" SET "match_request_id" = 'c607789f-4816-4a38-844b-173fa7bf64ed'::uuid WHERE "my_table"."id" = 129624354;

的输出 EXPLAIN (ANALYZE VERBOSE BUFFERS COSTS)

 Update on public.my_table  (cost=0.56..8.58 rows=1 width=832) (actual time=34106.965..34106.966 rows=0 loops=1)
   Buffers: shared hit=431280 read=27724
   I/O Timings: read=32469.021
   ->  Index Scan using my_table_pkey on …

我目前有一个看起来像这样的表：

CREATE TABLE "PDPC".collection
(
    col_no bigint NOT NULL DEFAULT nextval('"PDPC".collection_col_no_seq'::regclass),
    q1 character varying(10000) COLLATE pg_catalog."default",
    q2 character varying(10000) COLLATE pg_catalog."default",
    q3 character varying(10000) COLLATE pg_catalog."default",
    q4 character varying(10000) COLLATE pg_catalog."default",
    dg_fkey bigint,
    CONSTRAINT collection_pkey PRIMARY KEY (col_no),
    CONSTRAINT collection_dg_fkey_fkey FOREIGN KEY (dg_fkey)
        REFERENCES "PDPC".datagroup (dg_no) MATCH SIMPLE
        ON UPDATE NO ACTION
        ON DELETE NO ACTION
)
WITH (
    OIDS = FALSE
)
TABLESPACE pg_default;

ALTER TABLE "PDPC".collection
    OWNER to postgres;

我正在尝试使用 postgresql 在 PHP 中执行 UPSERT 语句，但我收到了

致命错误：未捕获的 PDOException：SQLSTATE[42P10]：无效的列引用：7 …

在 Postgres 13 中，我有一个经常更新的表。然而，更新查询相当复杂，并且多次使用相同的值。因此，使用 CTE 似乎是一件非常合乎逻辑的事情。

一个简化的示例如下所示：

WITH my_cte AS (
    SELECT
          my_id,
          CASE WHEN my_value1 > 100 THEN 50 ELSE 10 END AS my_addition     
    FROM my_table      
    WHERE my_id = $1
)
UPDATE my_table
        SET my_value1 = my_table.my_value1 + my_cte.my_addition,
            my_value2 = my_table.my_value2 + my_cte.my_addition
FROM my_cte
WHERE my_table.my_id = my_cte.my_id

现在我想知道：如果在SELECTCTE 和 之间UPDATE，表被另一个查询更新，my_value1从而发生变化，那么当发生这种情况时，were 的计算my_addition就会变得过时且错误，会发生什么UPDATE。会出现这样的情况吗？或者 Postgres 是否自动设置隐式锁？

如果 Postgres 在这里没有魔法，我需要自己处理它：FOR UPDATE在SELECTCTE 中做就足够了吗？

抱歉，如果我没有在这里说清楚：我并不是想“看到”这些并发修改，我想阻止它们，即一旦计算完成SELECT，没有其他查询可能会修改该行，直到计算UPDATE …