我正在苦苦挣扎，试图了解如何最好地编写我的代码和查询
直截了当地问：我是否需要或将来需要在事务中明确写入 LOCK IN SHARED MODE 或 FOR UPDATE（READ UNCOMMITTED 除外）？
如果我有外键，是否需要显式选择行以将锁定应用于这些行，或者外键定义就足够了？
【问题讨论】：
标签： php mysql transactions foreign-keys innodb
简短的回答：绝对是的。
完整的答案：这取决于用例。也许在大多数情况下，InnoDb 使用的默认锁就足够了。这些锁确保您的数据在事务中是一致的。但这里有一个需要使用SELECT ... FOR UPDATE 锁定的场景：
假设您正在制作一个 Web 应用程序，其中您的会话数据存储在数据库中。 Race condition is a concern 涉及会话数据。虽然当文件用于存储会话数据时会满足这种担忧，但如果将它们移动到数据库，则您有责任确保请求不会覆盖彼此的会话更改。在这种情况下，您需要使用FOR UPDATE 从 MySQL 读取会话数据，以确保其他请求将等待此会话写回会话并提交事务，然后才能读取它。
[更新]
这是共享模式的一个用例：
当您想确保某些记录在交易结束前保持不变时，共享模式非常有用。例如当您尝试将具有外键的子记录插入父记录时，而父记录已插入到先前的事务中。在这种情况下，您将首先选择锁定在共享模式下的父记录，然后尝试插入子记录，以确保在插入子记录时，父记录仍然存在。这样其他会话仍然可以读取父记录，但没有人可以更改它。这只是我的想法，但在共享模式锁定的所有用例中，这一事实仍然是相同的，即您希望记录保持不变，同时其他人仍可以读取它。
[更新]
关于SERIALIZABLE的事务隔离级别，MySQL's documentation很清楚。如果您以这种方式设置事务级别以及SET autocommit = 0;，那么它与REPEATABLE READ 级别完全一样，并且在最后用LOCK IN SHARE MODE 编写所有选择查询（除非您明确提及FOR UPDATE）。这意味着您将触摸的所有内容（显式或隐式）都将被锁定。那些被选中而没有提及锁或带有LOCK IN SHARED MODE的那些被锁定在共享模式，其余的被锁定在独占模式。
【讨论】：