Chociaż powyższa odpowiedź jest prawdziwa, ponieważ polecenie SELECT ... FOR UPDATE zapobiegnie wstawianiu tego samego rekordu przez współbieżne sesje/transakcje, nie jest to jednak pełna prawda. Obecnie walczę z tym samym problemem i doszedłem do wniosku, że SELECT ... FOR UPDATE jest w tej sytuacji prawie bezużyteczny z następującego powodu:
Równoczesna transakcja/sesja może również wykonać SELECT...FOR UPDATE na tym samym rekordzie/wartości indeksu, a MySQL z radością zaakceptuje to natychmiast (bez blokowania) i bez zgłaszania błędów. Oczywiście, jak tylko druga sesja to zrobi, twoja sesja również nie może już wstawić rekordu. Ani twoja, ani druga sesja/transakcja nie dostają żadnych informacji o sytuacji i myślą, że mogą bezpiecznie wstawić zapis, dopóki faktycznie nie spróbują tego zrobić. Próba wstawienia prowadzi albo do zakleszczenia, albo do błędu zduplikowanego klucza, w zależności od okoliczności.
Innymi słowy, SELECT ... FOR UPDATE zapobiega wstawianiu odpowiednich rekordów przez inne sesje, ALE nawet jeśli wykonasz SELECT ... FOR UPDATE i odpowiedni rekord nie zostanie znaleziony, istnieje prawdopodobieństwo, że nie możesz tego zrobić wstaw ten rekord. IMHO, który renderuje metodę "najpierw zapytanie, a następnie wstaw" bezużyteczną.
Przyczyną problemu jest to, że MySQL nie oferuje żadnej metody naprawdę zablokować nieistniejące rekordy. Dwie współbieżne sesje/transakcje mogą jednocześnie blokować nieistniejące rekordy „DO AKTUALIZACJI”, co naprawdę nie powinno być możliwe i znacznie utrudnia rozwój.
Wydaje się, że jedynym sposobem na obejście tego jest użycie tabel semaforów lub zablokowanie całej tabeli podczas wstawiania. Więcej informacji na temat blokowania całych tabel lub używania tabel semaforów można znaleźć w dokumentacji MySQL.
Tylko moje 2 centy...
