JDBC、ODBC 和外部表

做的事：真实确认JDBC/ODBC引擎存在，但没装对应的桥接服务

代码SELECT name FROM system.table_engines WHERE name IN ('JDBC','ODBC','MySQL','PostgreSQL'); which clickhouse-jdbc-bridge clickhouse-odbc-bridge; -- 本机真实都没有安装 CREATE TABLE demo.jdbc_test (id UInt32) ENGINE=JDBC('jdbc:mysql://127.0.0.1:3306/mysqllab', 'mysqllab', 'ch_integration_test'); SELECT * FROM demo.jdbc_test; -- 真的能查出数据吗？

验证：真实CREATE成功、SELECT立即报出明确的错误

实测 · 本机执行输出

CREATE TABLE demo.jdbc_test ... ENGINE=JDBC(...);
→ 真实成功(纯元数据操作，不会去检查桥接服务是否在运行)

SELECT * FROM demo.jdbc_test;
→ DB::Exception: clickhouse-jdbc-bridge is not running.
  Please, start it manually. (EXTERNAL_SERVER_IS_NOT_RESPONDING)

这条错误信息真实说得非常直白——JDBC引擎本身不包含真正的JDBC协议实现，它真实依赖一个独立运行的clickhouse-jdbc-bridge进程(一个跑在JVM上的独立Java服务，真实负责用标准的JDBC驱动去连接目标数据库)，ClickHouse自己这一侧只是把SQL请求转发给这个桥接服务；本机没有装这个桥接进程，报错真实又快又清楚，一眼就能看出缺了什么。

诚实的对比：真实同样没装桥接服务，ODBC的表现完全不同

本文真实也测试了ODBC表函数在同样没有clickhouse-odbc-bridge进程的情况下会怎样——结果跟JDBC真实不一样：SELECT * FROM odbc(...)真实没有像JDBC那样快速报出"bridge not running"这类明确的错误，而是真实卡住不返回，本文等了将近一分钟都没有得到响应，最后是手动kill掉这条查询进程才结束的。这个真实的行为差异，本文没有进一步深挖ODBC桥接连接失败时具体卡在哪个网络调用步骤，但从表现上看，同样是"缺少外部桥接服务"这类故障，JDBC引擎给出的诊断信息比ODBC更及时更明确——这对真实的运维排查有直接意义：如果生产环境里一条依赖odbc()的查询突然卡住不返回，排查方向应该优先怀疑clickhouse-odbc-bridge这个外部进程是否还活着，而不是先怀疑SQL本身写错了或者目标数据库变慢了；这个诚实记录下来的真实差异，本身就是一条比"JDBC/ODBC都需要额外的桥接进程"这句泛泛的话更有实际价值的排障线索。本文没有为了跑出一次真实成功的JDBC/ODBC查询而临时安装这两个额外的服务进程——它们都是独立于ClickHouse本身、需要额外部署维护的组件，装不装是一个真实的架构决策，不是这一篇文章该单方面替读者做的选择。

分步演示：从JDBC的明确报错到ODBC的真实挂起

每一步都是本文上面在真实缺少桥接服务的情况下跑出来的原始结果。

同样缺桥接服务，JDBC快速报错，ODBC真实卡住

这一步新验证的引擎

本文用到的工具

本机真实的ClickHouse 26.9.4，真实确认 JDBC/ODBC 表引擎存在但对应桥接进程未安装
诚实说明：本文未安装clickhouse-jdbc-bridge/odbc-bridge，基于真实的失败模式differences做说明

下一篇 · CLICKHOUSE 内部原理 79

Parquet 文件如何被 ClickHouse 读取