我们刚从MySQL迁移到PostgreSQL,每分钟的特定行都会大量更新。产品在MySQL中运行的那段时间我们都没有问题,但是在转移到PostgreSQL之后,我们遇到了很多死锁。
表结构。
Create table tab(col1 int , col2 int , col3 int, PRIMARY KEY(col1));
没有索引。
死锁查询 -
Update tab set col2=col2+1 where col3=xx;
(是的,结果会有多行。)
我的问题:MySQL如何处理这种情况以避免死锁? (问这个问题,假设PostgreSQL中关于这个查询的问题是因为每次发生并发更新时都以不同的顺序获取行)。
我可能也遇到了MySQL的死锁问题,但绝对不是PostgreSQL的发生程度。
我已经完成了https://dba.stackexchange.com/questions/151813/why-can-mysql-handle-multiple-updates-concurrently-and-postgresql-cant中发布的问题 这里发布的答案并不十分令人信服,因为作者全都抱怨PostgreSQL和HOT更新的更新架构。
我想知道架构的不同,使MySQL能够避免这个问题。
答案 0 :(得分:1)
猜测,MySQL(可能是InnoDB表)可能每次都以一致的顺序进行更新,而PostgreSQL的访问通常是无序的。这是有道理的,因为InnoDB使用索引组织表而PostgreSQL使用堆。
不幸的是,PostgreSQL不支持UPDATE ... ORDER BY
。您可以在UPDATE
之前进行行锁定,以确保以额外的往返为代价进行可靠的订购,例如
BEGIN;
SELECT 1 FROM tab WHERE col3 = xx FOR UPDATE;
UPDATE tab SET col2=col2+1 WHERE col3=xx;
COMMIT;
(我很乐意在PostgreSQL中获得UPDATE ... ORDER BY
支持。欢迎补丁!)