是否有 mariadb/mysql 的原生 C++ 连接器，它不仅仅是旧 c 连接器的包装器？

Question

有没有人发布过 mariadb/mysql 的本机 c++ 连接器，它不是 c 连接器 api 的包装器？我用 google 搜索了一圈，没找到任何东西。

我问的原因是判断使用 c++ 连接器的最终价值与仅在没有包装器 "middle man" 的情况下实现 c 连接器本身。每种编程语言最终都只是 cpu 和程序员之间的人机界面。有些语言比其他语言更巧妙地呈现和更强大，但它们仍然只是接口。我们有...

dbase 引擎 <- c 连接器 <- c++ 包装器 <- 应用程序

对比

dbase 引擎 <- c 连接器 <- 应用程序

这样做的唯一优势是程序员不必自己进行从 C 类型到 C++ 类型的转换和 类 吗？

为什么我不直接使用旧的 C 连接器而忽略 C++ 包装器？由于 "middle man"?

是否会导致性能下降？

Answer 1

可能没有本机 C++ 连接器（对于 MySQL/MariaDB），因为 libmysqlclient 有一个 C API，并且因为该库和服务器之间的网络协议没有很好的记录或定义。据传该协议已更改数次（MySQL 版本）。

关于性能，在实践中并不重要，因为大多数时候 SQL 服务器与客户端不在同一主机上，所以有真正的网络连接（例如 1Gbit/sec 以太网）在它们之间——实际上这已经是一个瓶颈（SQL 服务器和客户端在同一主机上的情况可能有所不同，例如在 localhost 上；但这不是很常见）。典型的网络交互意味着千字节在线路上，也就是几毫秒。

顺便说一句，几个（可能是大多数）SQL 请求可能需要真正的硬盘访问（至少当整个数据库大到无法放入 RAM 时），这意味着很多毫秒。 （使用 SSD 磁盘速度更快）。

所以在实践中，通过两层连接器通常并不重要（这只需要几十微秒）。

顺便说一句，如果您遇到数据与数据库客户端位于同一台机器上的罕见情况，您可以考虑 Sqlite instead. If performance is very important to you, you might give up SQL and use indexed files à la GDBM

据我所知，索引在性能方面比两层连接器重要得多：良好的索引可以避免多次磁盘访问！

^{当然，我正在考虑不适合 RAM 的足够大的数据库。如果您的数据库只有一百兆字节，那么所有内容都位于 RAM 中。而且我不是数据库专家或 MySQL}

自 MySQL (& Mariadb) is free software 以来，您可以研究 libsqlclient 的源代码，了解协议的所有细节，并用正版 C++（或在Ocaml 等）。但是我觉得不值得。

Answer 2

是：https://launchpad.net/mariadb++

但是没有文档，自从它首次发布两年多以来还没有看到任何更新。