许多死锁可以避免；有些人不能。没有一种技术可以防止所有死锁。 FOR UPDATE 似乎比 LOCK IN SHARE MODE . (我很想听到有人反驳。） 通常的模式似乎是：
BEGIN;
SELECT ... FOR UPDATE; -- use the columns fetched; lock the row(s)
-- Note: the locked rows may or may not actually be UPDATEd later
-- Note: FOR UDPATE prevents other connections from grabbing the same row(s)
UPDATE/DELETE/... -- those rows.
COMMIT;
但是。。。上面的任何内容都不能阻止经典的死锁场景：
BEGIN; -- connection 1
SELECT row 123 FOR UPDATE;
SELECT row 234 FOR UPDATE;
...
与
BEGIN; -- connection 1
SELECT row 234 FOR UPDATE;
SELECT row 123 FOR UPDATE; -- Note: locking order was swapped
...
1条答案
按热度按时间jobtbby31#
许多死锁可以避免；有些人不能。没有一种技术可以防止所有死锁。
FOR UPDATE似乎比LOCK IN SHARE MODE. (我很想听到有人反驳。）通常的模式似乎是：
但是。。。上面的任何内容都不能阻止经典的死锁场景：
与
没有做某种形式的工作
SELECT ...LOCK/UPDATE很容易导致“竞争条件”，即两个连接以不一致的方式作用于同一行。另一个注意事项：如果您以相同的顺序“锁定”相同的行，那么一个连接可能会暂停，直到另一个释放(囊性纤维变性
innodb_lock_wait_timeout，默认值为50秒（我认为时间过长）（我的所有讨论都应适用于mysql或mariadb中的innodb/xtradb的所有版本。）