我们刚刚从 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 能够避免此问题的架构差异。
最佳答案
据推测,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
。欢迎打补丁!)
关于mysql - 并发更新 MySQL 与 PostgreSQL?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/40645416/