标签: update

这可能是一个幼稚的问题，但这两个查询有什么区别，哪个是首选？

UPDATE table1, 
(SELECT id,COUNT(*) idcount FROM table2 GROUP BY id) AS B 
SET table1.Freq = B.idcount WHERE table1.id=B.id

和

UPDATE table1 A INNER JOIN 
(SELECT id,COUNT(*) idcount FROM table2 GROUP BY id) B USING (id) 
SET A.Freq = B.idcount

CREATE TABLE Table_1 (
    Id INTEGER PRIMARY KEY  AUTOINCREMENT  NOT NULL ,
    EmailId VARCHAR
)

INSERT INTO Table_1 VALUES (1,'raj@gmail.com');
INSERT INTO Table_1 VALUES (3,'test@gmail.com');
INSERT INTO Table_1 VALUES (4,'false5@gmail.com');
INSERT INTO Table_1 VALUES (7,'false55@gmail.com');
INSERT INTO Table_1 VALUES (8,'falsefalse@gmail.com');
INSERT INTO Table_1 VALUES (9,'true1@gmail.com');
INSERT INTO Table_1 VALUES (11,'true2@gmail.com');
INSERT INTO Table_1 VALUES (12,'falsefalsefalse@gmail.com');
INSERT INTO Table_1 VALUES (13,'ravi@gmail.com');
INSERT INTO Table_1 VALUES (14,'rak@gmail.com');
INSERT INTO Table_1 VALUES (15,'false@gmail.com');
INSERT INTO Table_1 VALUES (16,'false66@gmail.com');


CREATE TABLE Table_2 (
    Id …

我正在调查由两个并发 UPDATE 语句引起的死锁：

UPDATE [table] 
SET [column] = 0 
WHERE [unindexed_column] = @id

我的理解是，因为WHERE预测的列是未索引的，所以执行了全表扫描。对于每一行，获取一个更新锁。如果它与WHERE子句匹配，则它升级到排他锁并保持它直到语句完成。

当会话 A 拥有第 2 行的排他锁并试图获取第 1 行的更新锁，而会话 B 拥有第 1 行的排他锁并试图获取第 2 行的更新锁时，就会发生死锁。

死锁的原因是有道理的，但我不完全理解如何执行表扫描使这种情况成为可能。如果两个查询以相同的顺序执行扫描，最坏的情况似乎是其中一个查询在获取更新锁时被阻塞，直到另一个查询完成并释放它的锁。

表扫描是如何执行的？表格行的扫描顺序是否不一致？如果更新语句未能获得更新锁，它是否会转到下一行并稍后再次尝试上一行？究竟是什么让这种僵局成为可能？

我收到一个非常奇怪的错误。考虑下表：

CREATE TABLE #MyTable (
    Key1 INT , Key2 INT ,
    x SMALLINT , y INT , z INT ,
    a FLOAT , b FLOAT , c SMALLINT , s FLOAT
)

-- insert many records

CREATE UNIQUE CLUSTERED INDEX CI ON #MyTable ( Key1 , Key2 )

出于某种原因，以下更新语句尝试除以零。这只能在c=0或 时发生c=1。该WHERE条款明确规定c>1。

-- this fails with divide-by-zero error
UPDATE  #MyTable
SET s = CASE
        WHEN a - SQUARE ( b ) / c <= …

我有一个数据库表，users具有不同的用户名大小写（参见示例）。如何将字母更新ACCOUNTS\为小写？

ACCOUNTS\James.McAvoy
ACCOUNTS\michael.fassbender
ACCOUNTS\nicholas.hoult
ACCOUNTS\Oscar.Isaac

更新后的期望结果：

ACCOUNTS\james.mcavoy
ACCOUNTS\michael.fassbender
ACCOUNTS\nicholas.hoult
ACCOUNTS\oscar.isaac

我想设置status到false所有行除一人外，应应设置为true。我怎样才能做到这一点？

这是我试过的查询：

UPDATE students set status = false where status = true and 
set status = true where _id = 1;

出于测试目的，我使用pg_restore. 在新数据库中，我运行匿名化敏感数据的 SQL 查询。但是，像下面这样的查询会更新一个表中超过 2000 万条记录，该表具有约 10 个索引（在 期间创建pg_restore）。

UPDATE users SET email = users.id || '@example.com',
phone_number = NULL;

这需要几个小时的当前设置。

为了加快速度，我想为了运行而禁用表的索引update，然后再次启用它们并重新索引表。我怎样才能做到这一点？还有其他方法可以加快速度UPDATE吗？

笔记：

1. 我试过了

   UPDATE pg_index
   SET indisready=false
   WHERE indrelid = (
       SELECT oid
       FROM pg_class
       WHERE relname='users'
   );
   

   Run Code Online (Sandbox Code Playgroud)

但得到了下面的错误。

ERROR:  permission denied for relation pg_index

显然，您不能在 AWS RDS PostgreSQL 实例中以超级用户身份执行此操作。

2. 删除索引然后再次创建它们会很不方便，因为我必须提前知道它们涵盖哪些列。理想情况下，我会有一个命令将现有的索引配置存储在某个临时变量中，然后使用此信息重新创建它们。

我的任务是更新数据库中的几行。有两列，其中一列是ID，另一列是CURRENCY。我已经使用下面的更新语句更新了这些行：

update account set currency = 'INR' where id =15;
update account set currency = 'EURO' where id =12;
update account set currency = 'DOLLAR' where id =18;
update account set currency = 'Pound' where id =13; 
-- and so on.

实际上，在这种情况下，由于行数相对较少，我可以使用这些更新语句轻松完成，但是如果有数千或数十万行怎么办？这是更新它们的唯一方法，还是有其他方法或脚本？

我正在使用一个相对复杂的系统，其中根据需要从多个数据源更新静态表，因为动态加载数据需要 4-5 秒，我们更喜欢快速向用户显示结果。

过程：

1. 用户或应用程序打开特定订单
2. 调用存储过程来检索数据（我们称之为 dbo.Get_Data）
3. dbo.Get_Data 检查事件日志以查看自上次查找数据以来是否有任何更改
4. 如果它发现一个新事件，它会运行昂贵的查询来更新数据
5. 数据返回

IF (    SELECT [LastStaticUpdateEvent] < [LastSaveEvent] 
        FROM [dbo].[Events] 
        WHERE [OrderNumber] = @OrderNumber
    )
    BEGIN
       -- Update Static table
       UPDATE [Static]
       SET [Static].[A] = [App].[A]
          ,[Static].[B] = [App].[B]
       FROM [dbo].[AppData]            AS [App]   -- View with many joins (4-5 secs)
       INNER JOIN [dbo].[StaticResuts] AS [Static]
           ON [Static].[OrderNumber] = [App].[OrderNumber]
       WHERE [App].[OrderNumber] = @OrderNumber

       -- Update Event Log
       UPDATE [dbo].[Events]
       SET [LastStaticUpdateVent] = SYSDATETIME()
       WHERE [OrderNumber] = @OrderNumber

    END

SELECT * FROM …

我有两个进程并行执行这样的代码：

begin;
update foos set unread=false where owner_id=123 and unread=true;
commit;

这会导致死锁。

我对导致死锁的原因的理解就像这个问题中描述的场景，“交织” UPDATE 语句以不同的顺序更新两个不同的行。我不明白单个 UPDATE 语句如何导致死锁。我无法在我的开发环境中使用两个并行 psql 会话来复制死锁场景。我为什么不能复制它的猜测：

1. 我误解了导致死锁错误的代码，并且每个事务中实际上有多个 UPDATE 语句
2. “交织”方面正在发生，但“在”涵盖多行的 UPDATE 语句中，因此很难复制。

这个单一的 UPDATE 是否有可能造成死锁？