MySQL 更改了管理外键约束和级联操作的方式。从 MySQL 9.6 开始，外键验证和级联操作将由SQL层处理，而不是InnoDB存储引擎。这有助于改善变更跟踪、复制精度和数据一致性，使 MySQL 在 CDC 管道、混合数据库环境和分析工作负载中更加可靠。
长期以来，从事变更数据捕获（CDC）和复制工作的 MySQL 从业者都面临着一个很大的限制：外键由 InnoDB 存储引擎管理，级联更改未记录在二进制日志中。甲骨文技术顾问Prabakaran Thirumalai写道：
历史上，MySQL 在存储引擎层强制执行外键约束和级联操作……所有级联操作都是在 InnoDB 内部执行……因为 SQL 引擎和二进制日志不知道这些更改，所以下游系统（如 CDC 管道和分析平台）可能会错过它们。这可能导致数据不一致、分析不可靠和复制问题。
例如，SQL 层向 InnoDB 发出一个 DELETE 语句，InnoDB 可能会根据级联规则自动删除子表中的行。目前，这些额外的删除操作完全是在存储引擎内处理的，并未记录在二进制日志中。二进制日志仅捕获针对父表的原始 DELETE，而不捕获针对子表所做的更改。
图片来源：甲骨文博客
这一更改将在 MySQL 9.6.0 中实现。这是一个创新版本，在 1 月份作为 MySQL 9.x 创新系列的一部分提供。对于这一变化，社区的一个担忧是对性能的潜在影响。Thirumalai 补充道：
在针对常见的事务型工作负载所做的广泛的基准测试中，基于 SQL 引擎的外键强制执行和级联操作与 InnoDB 方法几乎相同。外键检查和级联操作的成本基本保持不变，吞吐量或延迟并没有观察到任何退化。
在Hacker News上一个热门的帖子中，Index Hint 所有者和首席工程师 Evan Elias 写道：
很高兴甲骨文为此写了一篇博文，因为 MySQL 的文档中几乎完全没有提及此事……MySQL 9.6 的发布说明根本没有提到外键变化……作为一个专注于 MySQL 解决方案的独立软件供应商，老实说，我觉得这种情况非常令人担忧。我听说，甲骨文的一位高管对重新关注 MySQL 社区版做出了很多承诺……如果连基本的文档更新都不做，我们还能认真看待这些承诺吗？
这一变化发生在社区许多人质疑甲骨文对 MySQL 及其社区版所做的承诺之际。社区会议正在讨论 MySQL 的未来。为了扩展 MySQL 的能力，新的跟踪分叉已在开发当中。在题为“MySQL 9.6：外键级联操作终于进入二进制日志”的文章中，ReadySet 高级软件工程师Marcelo Altmann评论道：
对于那些多年来一直在解决级联可见性限制的 MySQL 用户——或者更糟，在下游系统出现数据不一致后才发现这个问题——MySQL 9.6 填补了一个重要的架构空白。二进制日志终于能够完整地讲述你的数据发生了什么。
Uber 高级软件工程师 Banty Kumar指出：
如果甲骨文提供长期支持，那将是一个非常有说服力的升级理由。
根据公告，甲骨文团队计划未来在更多的存储引擎中提供更广泛的级联更改和外键强制执行支持。MySQL 9.6.0可以从MySQL社区服务器下载页面上下载。
声明：本文为 InfoQ 翻译，未经许可禁止转载。
