Navicat 17无专用“高性能分析连接”模式，性能取决于协议、端口、认证和驱动的精准匹配；必须选ClickHouse驱动（非MySQL/ODBC），Host填公网地址、Port填9000，服务端需启用allow_empty_password=1且配置compress=1、secure=1等参数。
Navicat 17 本身不提供 ClickHouse “高性能分析连接”的专用模式，所谓“高性能”完全取决于你是否正确匹配协议、端口、认证和驱动类型——错一个，连接就卡在 Connection refused 或 Authentication failed，根本谈不上性能。
必须选 ClickHouse 驱动，不能选 MySQL 或 ODBC
这是 90% 连接失败的根源。Navicat 17 的界面里，“数据库类型”下拉菜单中同时存在 MySQL、PostgreSQL、ClickHouse 等选项，但 ClickHouse 原生协议与 MySQL 协议完全不互通。服务端收到 MySQL 握手包会直接断连，日志里甚至不记鉴权失败，只留 Connection refused。
- 务必手动选
ClickHouse（不是MySQL，也不是ODBC） - 如果列表里没有
ClickHouse，说明你安装的是 Lite 版，或未启用 Premium 模块 - 旧版 Navicat（15 起）已内置原生驱动，Navicat 17 只是延续并稳定了它，无需额外装 ODBC
Host 和 Port 必须匹配 ClickHouse 原生协议端口（通常是 9000）
云环境（阿里云 CK、ByteHouse、腾讯云 TCHouse）极少开放 9000 端口给公网，默认只开 8123（HTTP 接口）。但 Navicat 17 的 ClickHouse 驱动仅支持原生 TCP 协议（即 9000），不支持 HTTP 模式——这点和 DBeaver 不同。
-
Host填控制台显示的“公网地址”，不是内网域名（如ck-xxx-public.clickhouse.aliyuncs.com） -
Port必须是9000；若云厂商只开放8123，则此路不通，得换工具或联系厂商开通原生端口 - 填了
8123却选ClickHouse驱动 → 报Code: 210. DB::NetException: Connection refused
空密码场景下，服务端必须允许空密码
很多本地部署或 Docker 启动的 ClickHouse 默认用 default 用户且无密码，但 Navicat 17 会强制发送空密码字段。如果服务端 /etc/clickhouse-server/users.xml 中该用户的 0，就会报 Code: 516. DB::Exception: default: Authentication failed。
- 检查路径：
/etc/clickhouse-server/users.xml→ 找到default - 确认含
1 - 改完需重启服务：
sudo systemctl restart clickhouse-server
Advanced 里要手动开 compress 和 secure（影响吞吐与延迟）
Navicat 17 的 ClickHouse 驱动支持协议层参数直通，但 UI 不默认开启关键优化项。不设 compress=1，大数据量查询时网络传输会成瓶颈；不配 secure=1（配合 TLS），云上跨机房连接延迟可能翻倍。
- 进连接设置 →
Advanced标签页 - 手动添加键值对：
compress=1（启用 LZ4 压缩） - 若服务端启用了 TLS：
secure=1，并指定 CA 证书路径（ssl_ca_cert） - 注意：
session_id、max_memory_usage等也可在此设，但不会同步到 Navicat Cloud
真正容易被忽略的是：Navicat 17 的“高性能”完全建立在协议栈干净、参数直通、驱动原生这三点上——它不帮你自动协商压缩、不绕过端口限制、也不适配云厂商的 HTTP-only 暴露策略。连都连不上，性能就是空谈。
