безспорно

он всегда в топе)

крудов для лары много вообщем то как и  админпанелей

Вот ! Я знал, что этим foregin ключам доверять нельзя.
Человек пишет:

"Сценарий: хорошо нагруженный кластер (Galera+MariaDB, несколько толстых машин). Есть таблица "users" в которой постоянно случаются LOW_PRIORITY обновления неключевых полей. Есть другая таблица с внешним ключом user_id. Делаем bulk-insert на 30000 строк в эту таблицу (транзакция, ~100 команд по 300 строк в каждой). Получаем deadlock и откат транзакции. Через N попыток повтора транзакции кластер начинает разваливаться под грузом блокировок.

Проблема описана Зайцевым ещё в 2006-м году: https://www.percona.com/blog/2006/12/12/innodb-locking-and-foreign-keys/

В общем пока что мы выключили внешний ключ на той «второй» таблице и оно заработало. "

Ребят как можно юзать whereHas на два разных коннекта
хотя таблица находится во втором, он ишет таблицу отношения в первом коннекте

хм перкона настолько давно существует

и всеж вопрос а разве мускуль вообще сам посебе нормально использовать для вставки сразу 30к строк?

А почему бы и нет
Там по 300 строк вставляли за транзакцию, кстати

а по 300

Главное, что innodb лочит родную таблицу из-за лока foregin keys в другой таблице
это просто эпик фейл
постгрес так не делает

а 8 мускуль так делает?

нафиг тогда нужны foregin keys, лучше вложиться в тесты кода на консистентность базы, чем получить вот такое поведение на продакшне внезапно

Неизвестно. Но если эта проблема тянется с 2006 - значит это в архитектуре InnoDB и это не лечится

чет прям интересно такое воспроизвести, но гемор еще тот))

коллеги. куда зарегать класс, чтобы напрямую вызывать в шаблонах blade ?

google -> laravel app service provider

)

)

taiwan