Всем привет. Подскажите, есть 2.5 млн записей, которые необходимо обновлять

по нескольким условиям и в несколько потоков желательно(10 например) столкнулся с такой проблемой, что происходит блокировка SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction. БД mysql - это поправимо? чтобы все работало быстро. Или необходимо рассматривать другие БД?

Проблема не в бд а в коде. Не видя твоего кода нельзя сказать в чем причина. Смена бд ничем не поможет.

Не факт... Может у него MyISAM-таблицы в мускуле...

InnoDB

а как оно работает? в цикле, в очереди?

м.б. кто-то еще туда пишет с транзакциями? Когда убрал та же ошибка?

https://stackoverflow.com/questions/5836623/getting-lock-wait-timeout-exceeded-try-restarting-transaction-even-though-im глянь, возможно есть зависшие транзакции. Их надо убить руками. Если таймаут слишком большой.

а по этому момменту вполне возможно, сейчас гляну, что-то там есть

Медленный апдейт может быть связан с настройками мускла. М.б. сейчас у вас сразу сброс данных на хдд при апдейте. И если диски медленные или забит io то будет притормаживать. Или каждый апдейт вызывает перестройку индекса (что маловероятно, если данные не меняются практически). Нужно исследовать все варианты.

При выполнении: SELECT * FROM information_schema.innodb_trx ORDER BY trx_started; у меня получается, что выполняется только 1 транзакция, остальные в ожидании

Как сказали выше транзакция не нужна. В innodb все апдейты и так в транзакцию завернуты. Первое что бы я посмотрел, есть ли индекс на source link. Поиск не должен занимать много времени. Второе посмотрел бы нет ли ненужных индексов, меньше индексов - проще перестраивать. Так же я бы убедился что нету попыток обновить одну и ту же запись одновременно.

На этот столбец индекс добавил только что, но есть другие индексы около 10 штук, для поиска. По другим индексам, их лучше удалять на время обновления, потом снова добавлять или оставить?

Не могу ответить на этот вопрос не зная специфики запросов ваших. Но если у вас 11 индексов на такую таблицу возможно вы действительно используете не ту бд или не так.

Если много ищите по данным возможно вам elastic стоит поверх накрутить, индексы посносить. Но перед любыми переделками я бы удостоверился, что проблема именно в этом. Например в песочнице снес бы все лишние индексы и посмотрел бы как ведёт себя приложение.

Очевидно, что этот код однопоточный. Чтобы он работал в N потоков, нужно его сделать многопоточным (ваш кэп). Крутить «чтобы блокировки снимались быстрее» можно, но упираться все равно будешь так или иначе с ростом нагрузки. Я бы посоветовал сам код сделать многопоточным. Ключевые слова - mutex, семафор и тд

Вообще "это черновая БД" в которую собирается вся информация, которую находит парсер, затем эта информация дополняется, обновляется по найденной дополнительной информации. Из этой базы уже будет строиться рабочая БД, в которой проставлены все связи и все структурировано. Рабочая БД будет загоняться в elastic. Пока примерно так

Т.е вся основная нагрузка приходится на этот черновой вариант) как и все операции по обработке данных

Для такого плана нагрузки может Kafka подойти

а через job ы нельзя сделать?

и так работает через Jobs

правильно, зачем разбираться с деадлоками, лучше другую бд взять :)

Ну поэтому мой первый и финальный совет - это как раз таки разобраться с дедлоками:) А насчёт Кафки - это не в смысле «эту проблему можно обойти, если взять кафку». Это в дополнение, что под подобный план нагрузки она может отлично подойти. Необходимости навыка решать проблему дедлоков никто не отменял ;)