为什么 Innodb Memcached 插件在 MySQL 8.0.22 中被弃用？

Question

我最初使用“handlersocket”插件来对 InnoDB 表进行 NoSQL 访问，然后它最终无法构建在较新的版本上，因此我迁移到了 Oracle 正在引入的“Memcached”插件，它似乎是一个很好的长期替代品。

现在插件文档上有一条通知，“InnoDB memcached 插件从 MySQL 8.0.22 开始已弃用”。

有谁知道为什么，其次，这是否意味着它不会再被烘焙，但在需要时仍然可以编译，或者插件的开发已经停止？如果是后者，是否有更新/不同的选项用于通过套接字访问表来跳过查询优化器的开销？我不明白为什么那些增加了如此多效率和灵活性的东西会被如此毫不客气地丢弃:(

Answer 1

memcached 插件从来没有跳过 InnoDB 的开销。它是一个 API，而不是存储引擎。发布到 memcached 插件的数据仍然受到事务处理，仍然写入 InnoDB 的重做日志，仍然缓存在缓冲池中，等等。您甚至可以通过 SQL 访问同一个表。memcached 插件的唯一优点是它跳过了 SQL 解析，并且因为除了主键之外您无法进行连接或搜索，这避免了许多复杂的优化选择。

我还没有看到一篇文章描述了他们弃用此插件的原因。但以下任何一个理由都是好的：

• 这是没有安全感的。默认情况下，memcached API 没有身份验证，这就是 memcached 插件中使用的方式。这是一个很大的安全漏洞，如果启用了 memcached 插件，文档会阻止用户在 MySQL 实例中存储“敏感数据”。

  对于数据库供应商来说，这是一个相当强烈的声明！如果一辆汽车的制造商说：“呃，你可能不应该让你的家人乘坐这辆车。”你会怎么想？

• 这很令人困惑。memcached API 是否提供对 memcached 实例的访问？不。与 memcached 类似，这是一个内存数据存储？不，它和 memcached 一样快吗？不。

• XDevAPI 提供 NoSQL 数据访问。这是一个功能更全面、更安全的 MySQL API，它支持像面向文档的数据库一样的数据。毫无疑问，MySQL 的产品经理更希望开发人员使用它，这样他们就可以对 MySQL 服务器中的数据进行非 SQL 访问有更好的解决方案。

• 那时还不够流行。您使用了 memcached 插件，但其他开发人员没有使用过。如果他们想使用memcached，实际使用真正的memcached服务并不难，它具有简单查询接口的相同优点，并且比MySQL中的memcached插件快2-3倍。