MySQL 无法更改正在积极写入的 ALTER TABLE

Question

在我的应用程序的一个用例中，我有两个并发的MySQL连接：一个主动写入名为的表T（实际上，不断更新该表中的一行），以及另一个对同一个表执行 DDL（ALTER TABLE添加 8 个新列并从varchar(80)到扩展一列varchar(2000)）。DDL 有望最终完成。在列UPDATEDML都不会受到DDL。该表仅包含一行（被UPDATE'd的那一行）。分析当运行覆盖此用例的集成测试时，我观察到的是测试超时（该表被如此积极地写入，因此 DDL 永远不会完成），但仅适用于MySQL 5.7。通常，测试预计在我们的硬件上在 30 秒内完成（MySQL 5.6 和 8.0确实会发生这种情况），但对于MySQL 5.7，即使 200 秒也不够。我已经尝试了不同的ALGORITHM和LOCK值（参见13.1.8 ALTER TABLE Syntax），但没有运气。当我分析我的应用程序（MySQL 5.7 案例）时，我观察到 99% 的 CPU 时间都花在从套接字读取上（即等待MySQL响应表已被更改），但数据库实例是一种黑色box 给我——当然我已经performance_schema启用并且可以针对它运行查询，但我不知道我正在寻找哪些确切的信息。合成同时，我未能将问题简化为最小的自包含单元测试——我观察到的唯一一件事是与其他MySQL版本相比，MySQL 5.7 的测试时间增加了3到10 倍，但 DDL 没有永远挂起：所有MySQL版本都是从www.mysql.com下载的适用于Windows或Debian Linux 的库存版本，对或官方Docker映像进行了最少的更改。my.cnf问题：MySQL在技术上真的可以ALTER TABLE永远延迟DDL的执行吗？或者我观察到的只是一个非常繁忙的数据库实例？是否可以ALTER TABLE可中断执行的请求，即如果超过某个超时时间，则数据库返回错误，或强制所有其他可能SHARED在表或其某些行上放置锁定的连接暂停，以便在执行 DDL 时它们不会进行干预？在处理原始集成测试超时时，如何从MySQL端进一步诊断情况？