Published on

用 mysql 客户端连接"兼容 MySQL 协议"的数据库

Authors

背景：协议兼容 ≠ 内核一致

越来越多的数据库（尤其一些分布式 / 国产数据库）提供了 MySQL 兼容协议层：它们对外说 MySQL 线协议，能用标准 mysql 客户端连，但底层内核可能是 PostgreSQL、自研存储、甚至完全不同的引擎。

这意味着：

  • 端口通常不是 3306，而是厂商自定义的兼容监听口；
  • 账号体系独立，往往有专门的"兼容账号"，而非 MySQL 原生账号；
  • 某些行为（如二进制列的展示、系统库的命名）与原生 MySQL 有差异。

下面以一套脱敏的连接配置为例，讲清楚每个参数的含义和踩坑点。

连接命令

mysql \
  -h 127.0.0.1 \
  -P 3306 \
  -u <mysql_compat_user> \
  -p'<your_password>' \
  --skip-binary-as-hex \
  -Dmysql

⚠️ 上面的 IP、端口、账号、密码均为占位符，请替换为目标数据库实际的兼容监听地址与凭据。

逐个参数说清楚

-h / -P：注意兼容监听口

兼容层通常监听在一个非标准端口上。常见的几种：

  • 沿用 3306；
  • 厂商自定义端口（如 3310、4410 等）；
  • 同一实例多个版本/租户时，会出现多个端口。

连接前务必确认文档里写的是"MySQL 兼容模式监听端口"，而不是管理端口或原生协议端口。连错端口会得到非常迷惑的报错（握手就失败）。

-u / -p：兼容账号

兼容模式下一般有一套独立的账号体系。可能出现的情况：

  • 原生 MySQL 账号无法登录兼容层；
  • 需要专门的兼容账号（命名常带 mysql 字样，示意用途）；
  • 初始/测试环境可能是空密码，但生产环境务必设置强密码。

--skip-binary-as-hex：避免"乱码"

这是最容易忽略、却最常让人困惑的一点。

很多兼容层默认把二进制类型（BLOB、VARBINARY 等）按 hex 字符串返回，于是你在终端看到的是：

+----------------------------------+
| col                              |
+----------------------------------+
| 0x48656C6C6F                     |
+----------------------------------+

而不是可读文本。加 --skip-binary-as-hex 让客户端按普通字符串展示，立刻清爽。

-Dmysql：指定初始库

直接进入某个系统库（如 mysql），避免连上后还要手动 USE。兼容层通常会暴露一组与 MySQL 对应的系统库：

  • information_schema
  • mysql
  • performance_schema
  • sys
  • 可能还有厂商自有的系统库（命名各异）

一个验证底层内核的小技巧

连上之后，执行：

SELECT VERSION();

原生 MySQL 会返回类似 8.0.x。而兼容层往往"露馅"——返回值里会带上真实内核的版本信息。比如某些基于 PostgreSQL 内核的兼容层会返回形如：

PostgreSQL xx.x (ProductName x.x.x) on ...

一眼就能看出"外壳是 MySQL 协议、内核是别的"。这在排查 SQL 方言差异（函数名、类型、语法）时非常有用：按真实内核的方言去查文档，往往比按 MySQL 文档查更准。

排错清单

连不上时，按这个顺序排查：

  1. 端口对不对——是不是 MySQL 兼容监听口？用 telnet <host> <port> 先验通。
  2. 账号对不对——用的是兼容账号，而非原生账号？
  3. 网络可达吗——兼容层是否只监听内网 / 特定网段？
  4. 协议版本——客户端和服务端的 MySQL 线协议版本是否兼容（旧客户端连新协议常报握手错误）。
  5. 看 VERSION()——连上后第一时间确认真实内核，再据此查文档。

小结

连接"兼容 MySQL 协议"的数据库，关键在于把心智模型从"它就是 MySQL"切换到"它说 MySQL 的线协议，但有自己的账号、端口和内核"。记住三件事：端口看兼容监听口、账号用兼容账号、必要时加 --skip-binary-as-hex——连上后用 VERSION() 探明真实内核，后续排错就有的放矢了。

Discuss on Twitter • View on GitHub