是否可以在具有FKs的其他表上插入具有FK影响操作的表到同一表？

Question

让我们假设InnoDB数据库上有以下表：

• 用户(id_user，名称)
• 日志(id_log，id_user，info)
• 消息(id_message，id_user_from，id_user_to，message)

id_user列在log和id_user_from上，id_user_to列在message表上，是FK到user(id_user)。

据我所知，如果存在，当我们在log表中进行插入时，user上的mysql 将在相关记录上创建共享锁。。如果另一个事务试图获得共享锁，它将正常工作。如果另一个事务试图获得独占锁，则必须等待第一个事务完成。。

我的问题是:如果另一个事务试图在message上进行插入或更新，引用user上相同的记录，那么它将受到log上插入的影响吗？我不这么认为，因为这个事务也会获得记录上的共享锁，但我在一些旧文章(10年前)上读到，这可能是一个问题。如果是这样的话，隔离级别会对此产生影响吗？再说一次，我不这么认为。

Answer 1

我在这方面的态度：

• 交易速度如此之快，几乎没有任何冲突。
• 使用SELECT ... FOR UPDATE“锁定”即将更新的行。(除非有办法避开它们。)
• FKs意味着额外的检查。这些需要时间。支票通常是多余的。
• 我不使用FK CASCADE，因为我喜欢在相同的代码中看到所有的交互--即BEGIN和COMMIT之间的代码。
• 我不使用非级联FKs，而是调试我的代码。
• 我确实使用了INDEXes，并且我想知道究竟存在哪些索引，并且不对额外的(冗余的)感到惊讶。由FKs创建的。
• 在每个SQL语句之后检查错误。这可能是令人惊讶的僵局。
• 即使在COMMIT之后也要检查错误。这是为了防止应用程序被迁移到Galera或InnoDB集群。
• 如果存在死锁，则在BEGIN重新启动。
• 小心“烧坏”的AUTO_INCREMENT ids。(这本身就是一个冗长的讨论。)

回到你的问题上。

有些情况下，InnoDB需要一个比它需要的更强的锁(例如，cases )。这可能是因为边缘情况太昂贵，无法检查。你的例子可能(也可能不是)就是这样的一个例子--我目前没有足够的脑细胞来思考。我回到我的第一个项目--让交易足够快，这样问题就解决了。