--单个事务--mysqldump的lock-tables选项--内部发生了什么？

Question

我确实找到了其他与此类似的帖子，但我想了解一些关于mysqldump的选项的额外信息。我知道--单事务和--锁-表是互斥的操作。以下是我关于这些选项的问题。

a)假设我选择使用--lock-tables选项。在本例中，mysqldump获取所有表上的一个读锁。因此，任何其他尝试写入表的进程都将进入阻塞(等待)状态。但是，如果mysqldump需要很长时间，那么正在等待的进程是否会无限期地继续等待？

例如，我尝试了这个实验--我有一个Java (JDBC)程序写入一个名为MY_TEST的mysql数据库表。我登录到mysql控制台，手动发出"LOCK TABLES MY_TEST READ;“命令。因此，Java进程在等待锁释放时被阻塞。我的问题是，如果长时间不释放读锁，是否会出现连接超时或任何此类问题？我等了两分钟，没有注意到任何错误，一旦使用"UNLOCK tables“命令释放了锁，java进程就会继续正常运行。这是特定于java mysql驱动程序的行为吗?或者我能期望使用mysql驱动程序的C程序也是如此吗？

b)我的第二个问题是关于--单事务选项。假设我有10个InnoDB表，其中3个表彼此相关(使用FK)，其他表是独立的，但仍然使用InnoDB引擎。单个事务是否仅适用于使用FK相互关联的3个表？或者，我能期望这7个独立表的状态与3个相互依赖的表被转储时的状态完全相同吗？

Answer 1

a.)我相信答案是肯定的，在mysql级别，连接将无限期地等待mysqldump释放表锁。您可以在应用程序级别控制这一点，方法是使用带有验证查询的连接池，该查询针对被锁定的表进行查询，并将检索的超时设置为您想要的任何值。例如，这在c3p0中很容易做到。然而，在缺乏其他信息的情况下，我不推荐这种方法；它看起来相当笨拙。我没有使用过mysql C驱动程序，所以我不能确定，但我会假设其行为类似于Java。所有这些都是为什么对于具有大量数据和活动的系统的实时备份来说，mysqldump不是一个好的选择。

b.转储的所有表将作为单个事务的一部分进行转储，从而为参与转储的所有表生成一致的快照。主键-外键关系对事务没有影响。使用单事务是热备份的可行选项。