Параллельное обновление MySQL против PostgreSQL?

Question

Мы только что перешли от 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 избежать этой проблемы.

Answer 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; 

(Я хотел бы иметь поддержку UPDATE ... ORDER BY в PostgreSQL. Патчи прием!)