是。虽然活动事务保持FOR UPDATE在记录上的锁，在使用任何锁其他交易报表（SELECT ... FOR UPDATE，SELECT ... LOCK IN SHARE MODE，UPDATE，DELETE）将暂停，直到无论是主动事务提交或“锁定等待超时”超过。
这将不是问题，因为这正是必需的。结帐交易应按顺序执行，即 后一个结帐不应在前一个结帐之前开始。
Repeatable reads隔离级别可确保在提交事务之前不可见事务所做的更改。因此，物品可用性将正确显示。在实际付款之前，不会显示不可用的任何内容。无需锁。
SELECT ... LOCK IN SHARE MODE会导致结帐交易等待完成。这可能会使结帐速度变慢而没有任何回报。
有可能的。当超过“锁定等待超时”或发生死锁时，事务可能会回滚。在这种情况下，最好自动重试。 默认情况下，挂起的语句在50秒后失败。
是的，SELECT ... FOR UPDATE在items桌子上就足够了。 是的，这些选择等待，因为FOR UPDATE是排他锁。 是的，简单的SELECT交易会像交易开始前那样获取价值，这将立即发生。
是的，SELECT ... FOR UPDATE，SELECT ... LOCK IN SHARE MODE，UPDATE，DELETE锁定所有读取记录，所以无论我们JOIN是包括在内。参见MySql Docs。
有趣的是（至少对我而言），无论是否选择，在处理sql语句时扫描的所有内容都会被锁定。例如，WHERE id < 10还会用id = 10！锁定记录！
If you have no indexes suitable for your statement and MysqL must scan the entire table to process the statement, every row of the table becomes locked, which in turn blocks all inserts by other users to the table. It is important to create good indexes so that your queries do not unnecessarily scan many rows.
602392714
清零编程群