MySQL транзакций: один большой сделки против нескольких мелких сделок

Question

Дизайн для крупной сделки ..

START TRANSACTION; 
    /* 
     INERT for login detail 
    */ 
    /* 
     INSERT for personal information 
    */ 
    /* 
     INSERT for user's transaction account 
    */ 
COMMIT; 

и дизайн для малых сделок ..

START TRANSACTION; 
    /* 
     INSERT for login detail 
    */ 
COMMIT; 

START TRANSACTION; 
    /* 
     INSERT for personal information 
    */ 
COMMIT; 

START TRANSACTION; 
    /* 
     INSERT for user's transaction account 
    */ 
COMMIT; 

Текущие результаты

• Я пробовал как в нашем приложении и с помощью транзакции «Большой» мы столкнулись с тупиком в определенной таблице.

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

Мой опыт в обработке таких случаев недостаточен для обеспечения наилучшего решения в этом виде сценария. Какое решение можно сделать здесь?

Answer 1

После нескольких лет опыта в моей работе , Я придумал это решение .. потому что данные для затронутых модулей все неповреждены благодаря успеху или неудаче. Спасибо всем за помощь

START TRANSACTION; 
    /* 
     INSERT for login detail 
    */ 
    /* 
     INSERT for personal information 
    */ 
    /* 
     INSERT for user's transaction account 
    */ 
COMMIT; 

Answer 2

Пункт использования транзакции заключается в обеспечении согласованности хранимых данных. Когда вы совершаете транзакцию, все вставки, обновления и удаления сразу не сохраняются в базе данных, DB блокирует таблицы (или строки в зависимости от конфигурации) с предварительными данными до тех пор, пока не достигнет команды commit. В этот момент данные записываются и блокировки освобождаются.

Если вы совершаете «небольшие» транзакции, то это то же самое, что вообще не совершать транзакции.

Если ваша «большая» сделка застревает, найдите, какая таблица вызывает тупик, и почему она это делает. Существует множество причин, включая одновременные вставки/обновления/удаления в таблице, блокировки не выпускаются вовремя, предыдущие транзакции остаются «живыми» (т.е. не достигают команды фиксации), БД занимает слишком много времени, чтобы хранить данные в таблице , слишком много времени между вставками, внешним ключом нарушением и т.д.

вы можете прочитать эту статью, которая объясняет, как работают транзакции и как вы можете определить и избежать ТУПИКИ http://flylib.com/books/en/1.142.1.79/1/