Проблем с блокиране на MySQL с InnoDB

Това причинява блокиране, тъй като UPDATE query заключва всички редове в таблицата и в зависимост от използваните индекси (или липсата на такива), две различни сесии потенциално ще ги заключат в малко по-различен ред. Запомнете това UPDATE , DELETE и SELECT ... FOR UPDATE ще заключи всички редове, които срещнат, независимо дали тези редове съответстват на всички WHERE условия или не. Така че, когато ги използвате, трябва да се постараете да сте сигурни, че срещат възможно най-малко редове, като използвате индекси (в идеалния случай първичния ключ) и избягвате неясни или широки условия за избор.

Моето предложение за работни опашки е почти универсално:заключвайте възможно най-малко, възможно най-рядко и винаги в детерминистичен ред. И така, общо взето:

1. Използване на незаключващи четения (обикновен SELECT ), за да намерите работа, като търсите неща, които вашият служител знае как да прави и в момента не са заявени (lease_owner IS NULL AND lease_expiry IS NULL -- или подобни).
2. Изберете един работен елемент (или няколко, ако смеете, но единият е далеч по-прост и обикновено позволява напълно приемлива производителност).
3. Актуализирайте своя работен елемент (за да го поискате, но за всеки случай той също се нуждае от актуализиране):
   1. Отворете транзакция.
   2. Заключете избрания от вас работен елемент с SELECT ... FOR UPDATE -- Ако вече не е непотърсен, прекъснете и изберете друг.
   3. Актуализирайте избрания от вас работен артикул с идентификационния си номер на работник и срок на изтичане на лизинга ви за него.
   4. Извършете транзакцията си незабавно.
4. Започнете работа по вашите наети работни елементи.
5. В някакъв друг процес друг анкетьор търси изоставена работа и я отменя (чрез същия процес на актуализиране по-горе).

Можете лесно да получите много висока пропускателна способност с този дизайн (хиляди задачи в секунда) и по същество без спорове и проблеми с поръчката. Оптимизациите за избор на работа, която е по-малко вероятно да бъде в конфликт с други анкетьори, са прости и ефективни (напр. модул на Job ID или подобен, избран, за да се избегне загуба на работни места). Ключът е да запомните, че конфликтът при избор на работа е добре -- просто прекъснете и опитайте отново и всичко се развива много бързо.

Всички заключващи записи за елементи/задачи от работната опашка трябва да се извършват само на единични редове и само чрез първичен ключ .