1.试图同时预订同一项目的其他用户将得到正确处理。 他的交易会T2
等到T1
完成吗？
是。虽然活动事务保持
FOR UPDATE在记录上的锁，在使用任何锁其他交易报表（
SELECT ... FOR UPDATE，
SELECT ...LOCK IN SHARE MODE，
UPDATE，
DELETE）将暂停，直到无论是主动事务提交或“锁定等待超时”超过。
2.使用PayPal或Stripe付款可能需要一些时间。 就性能而言，这不会成为问题吗？
这将不是问题，因为这正是必需的。结帐交易应按顺序执行，即 后一个结帐不应在前一个结帐之前开始。
3.项目可用性将始终正确显示（项目应该可用，直到结帐成功）。 这些只读选择是否应该使用shared lock
？
Repeatablereads隔离级别可确保在提交事务之前不可见事务所做的更改。因此，物品可用性将正确显示。在实际付款之前，不会显示不可用的任何内容。无需锁。
SELECT ... LOCK IN SHARE MODE会导致结帐交易等待完成。这可能会使结帐速度变慢而没有任何回报。
4. MySql本身是否可以回滚事务？ 通常，自动重试或显示错误消息并让用户重试通常更好吗？
有可能的。当超过“锁定等待超时”或发生死锁时，事务可能会回滚。在这种情况下，最好自动重试。
默认情况下，挂起的语句在50秒后失败。
5.如果我SELECT ... FORUPDATE
在items
桌子上做，我猜就足够了。这样，双击引起的请求和其他用户都必须等到交易完成。他们将等待，因为他们也使用FORUPDATE
。同时，vanilla SELECT
只会在事务之前看到db的快照，但是没有延迟，对吗？
是的，
SELECT ... FOR UPDATE在
items桌子上就足够了。
是的，这些选择等待，因为
FOR UPDATE是排他锁。
是的，简单的
SELECT交易会像交易开始前那样获取价值，这将立即发生。
6.如果使用JOIN
in SELECT ... FOR UPDATE
，两个表中的记录都将被锁定吗？
是的，
SELECT ... FOR UPDATE，
SELECT ... LOCK IN SHAREMODE，
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.
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）