Navicat 连接 TiDB 必须手动选择 TiDB 类型，因其虽协议兼容 MySQL，但认证插件、元数据查询、SSL 配置、对象树渲染等存在关键差异，选错将导致函数不存在、注释丢失、连接卡顿等具体报错。
Navicat 连接 TiDB 时被识别为 MySQL 兼容版本，不是因为 Navicat “认错了”，而是 TiDB 主动声明自己是 MySQL 兼容数据库——它在握手阶段就通过 ServerVersion 和 Capability Flags 向客户端（包括 Navicat）表明：“我支持 MySQL 协议，但我是 TiDB”。Navicat 基于此做出适配判断，而非简单打上“MySQL”标签。
Navicat 的 TiDB 连接类型为什么必须手动选，不能靠自动识别
Navicat 不会根据协议自动切换连接类型。即使 TiDB 在协议层完全兼容 MySQL，它仍需要显式选择 TiDB 连接类型，原因如下：
- 驱动行为差异：MySQL 驱动默认启用
caching_sha2_password认证插件，而 TiDB 默认只支持mysql_native_password；选错类型会导致Authentication plugin 'caching_sha2_password' cannot be loaded - 元数据查询逻辑不同：TiDB 的
information_schema字段含义、视图展开方式、索引描述格式与 MySQL 存在细微差别，专用驱动会绕过或重写这些查询 - SSL 配置入口不一致：MySQL 类型的 SSL 设置藏在高级选项里，TiDB 类型则强制暴露在主配置页，漏设直接导致
SSL connection error: unknown error number - 对象树渲染逻辑：视图、序列、分区表等在左侧导航栏是否可展开，取决于驱动是否识别 TiDB 特有对象类型
Connection Type 选错后最常触发的三个报错
选成 MySQL 而非 TiDB，不只是“连得上但功能少”，而是会引发具体可复现的失败：
-
ERROR 1305 (42000): FUNCTION load_file does not exist：Navicat 编辑视图时尝试调用该函数读取定义，TiDB 不支持，且 MySQL 驱动不会降级处理 - 表结构编辑保存后字段注释消失：MySQL 驱动用
SHOW CREATE TABLE解析，TiDB 返回的语法格式含额外空格或换行，导致解析失败 - 测试连接成功但双击数据库名后卡住/报超时：Navicat 尝试获取
performance_schema或sys库信息，TiDB 不提供这些库，MySQL 驱动未做兜底判断
Host 和 Port 看起来对，但连不上？先查这三件事
填了 127.0.0.1 和 4000 却连不上，问题往往不在 Navicat 配置本身：
- 检查
tidb-server是否监听0.0.0.0:4000，而非仅127.0.0.1:4000（config.toml中host = "0.0.0.0"） - Docker 场景下确认端口映射正确：
-p 4000:4000，而不是-p 4000:4001或漏掉-p - TiDB Cloud 用户必须用控制台 Connect 页面提供的 HOST/PORT，Serverless 实例虽常用
4000，但 Dedicated 实例可能用6000，硬填4000会直连失败
真正容易被忽略的是：TiDB 的“MySQL 兼容”是协议级兼容，不是行为级兼容。Navicat 的每个右键操作背后都是一组 SQL + 驱动逻辑，而 TiDB 对某些辅助函数（如 load_file）、系统库（如 performance_schema）、甚至空格敏感的 DDL 解析，都做了取舍。选对连接类型，本质是告诉 Navicat：“别按 MySQL 的习惯猜，按 TiDB 的文档来。”
