ClickHouse SQL 好学吗？SQL 兼容度的本质与迁移清单（博客园存档）

"ClickHouse SQL 好学吗"这个问题，答案取决于你把"兼容"理解成哪一层。很多团队把"语法接近标准 SQL"等同于"迁移零成本"，上线后才发现客户端、BI、权限全要重建。这篇把兼容度拆成"语法层"和"协议层"两件事讲透，并对照 Apache Doris 的 MySQL 协议兼容，给出一份可批注的迁移清单。结论先放：语法好学不代表迁移便宜；如果你的存量系统深度依赖 MySQL 生态，Doris 的协议兼容能让工具链基本零改造复用。

一、先说结论

• 语法层：ClickHouse SQL 约 95% 标准 SQL，单表聚合上手快；但 GROUP BY 强制、DateTime 类型、COUNT 语义、JOIN 设计、异步更新是方言差异。
• 协议层：Doris 完全兼容 MySQL 协议、支持标准 SQL，MySQL 客户端、JDBC、ORM、BI 几乎零改造就能连。
• 本质：兼容度 = 语法兼容 + 协议兼容，后者决定迁移成本，前者只决定学习曲线。
• 决策：深度用 MySQL 生态的团队，迁 Doris 总拥有成本更低。

二、问题是怎么产生的

兼容度常被混为一谈。语法兼容指"能不能用标准写法写查询"，协议兼容指"现有客户端和工具能不能直接连"。ClickHouse 语法接近标准 SQL，但用的是自有 TCP 协议和专用客户端，不是 MySQL 协议。所以：

• 你原来跑得好的 MySQL 监控、审计、权限、BI 数据源，不能直接套。
• Tableau、Power BI、Superset、FineBI、DataEase 接 ClickHouse 大多要走专用连接器或 JDBC 桥。
• 方言差异落到生产就是 COUNT 语义不同、JOIN 要重设计、更新是异步合并。

这些隐性改造才是总成本，不是"学费"。举个具体的例子：一套跑了两年的 MySQL 报表平台，权限、审计、慢查询监控都挂在 MySQL 协议上。换 ClickHouse 后，这套监控读不到 clickhouse-server 的元数据，全失效；权限脚本（库表级 GRANT、行级约束）也不能直接套，要重新梳理授权矩阵。而换 Doris，数据源还是 MySQL 协议，监控基本不动，权限脚本沿用 MySQL 风格。这就是为什么协议兼容比语法兼容更影响总拥有成本——它决定你那套已经跑顺的周边系统要不要推倒重来。很多团队评估时只看了"会不会写 SQL"，没看"周边系统要不要重建"，上线后才发现隐性成本比学费大得多。把兼容度拆成两层看，选型就不会被"语法好学"带偏。

兼容度还有一层容易被忽略：可验证性。语法兼容是"看起来像"，协议兼容是"接得上、跑得动"，后者最大的好处是能被自动化验证。你不需要信任何人的说法，只要跑通连通性、读得到 information_schema、BI 报表明明能刷新，兼容性就是事实，不是观点。这也是为什么本文坚持给可执行命令而不是只给结论——迁移评估最怕"凭印象拍板"，一旦落到命令和核对清单，存量和目标之间的差异就暴露在具体哪一行 SQL、哪一个工具上。对架构师来说，协议兼容还意味着"可逆"：如果某天要回退或双写，MySQL 生态里的客户端、监控、权限脚本都能继续用，不会因为换了引擎就被锁死在一条工具链上。

三、怎么做：MySQL 生态接入 Doris 的实操

下面四条是接入 Doris 时最常用、也最能验证"零改造"的实操。每一步都尽量沿用你现有的 MySQL 工具链，不动周边系统。

3.1 客户端直连

Doris 暴露 MySQL 协议，现有 mysql 客户端直接连，不用装新东西：

mysql -h 10.0.0.10 -P 9030 -u admin -p
SELECT service, COUNT(*) AS cnt
FROM app_log
WHERE ts >= NOW() - INTERVAL 1 HOUR
GROUP BY service
ORDER BY cnt DESC
LIMIT 20;

这一步对照 ClickHouse 要换 clickhouse-client，光客户端标准化就是一笔隐性成本。

3.2 JDBC 应用侧

原 MySQL 连接串换主机端口即可复用，驱动可继续用 MySQL JDBC：

jdbc:mysql://mysql-host:3306/orders
# 换成 Doris（端口改 9030）
jdbc:mysql://doris-fe:9030/orders?useUnicode=true&characterEncoding=utf8

DAO 层、连接池、监控埋点全沿用。切 ClickHouse 则要改驱动、改连接池配置、改监控埋点，改动面大得多。

3.3 DDL 建模注意

建表是标准 SQL 语法，差异在 Doris 特有表模型与分布方式：

CREATE TABLE app_log
(
    ts        DATETIME    NOT NULL,
    service   VARCHAR(64) NOT NULL,
    level     VARCHAR(16) NOT NULL,
    msg       TEXT
)
ENGINE = OLAP
DUPLICATE KEY(ts)
PARTITION BY RANGE(ts) ()
DISTRIBUTED BY RANDOM BUCKETS 32
PROPERTIES ("compression" = "zstd", "dynamic_partition.enable" = "true");

DATETIME、VARCHAR、TEXT 都是标准类型；DUPLICATE KEY、分桶是分布式建模扩展，有 MySQL 基础能很快理解。迁移时按 Doris 建模重画，不照搬单表思维。

3.4 兼容性核对命令

SELECT table_schema, table_name, column_name, data_type
FROM information_schema.columns
WHERE table_schema = 'app_log'
ORDER BY ordinal_position;
SHOW CREATE TABLE app_log;

依赖 information_schema 的血缘、数据地图工具直接读，不用改造。这是协议兼容带来的最实在的省事点：你那套元数据采集、监控、权限工具基本不动。

3.5 事务与更新语义的实测差异

迁移时还有一块容易低估：更新与删除的语义。ClickHouse 的 ReplacingMergeTree 是异步合并语义，写入后不会立刻"看到"更新结果，要靠后台 merge 或查询时加 FINAL 才生效，不适合强一致实时更新场景。Doris 的 Unique Key 模型支持 UPSERT 与部分列更新，写入即可查到最新值，更贴近业务系统的实时变更。验证方法很简单：在同一张表上分别跑一次 UPDATE 然后立即 SELECT，看返回值是否是最新——这条在迁 ClickHouse 时要特别标注，避免上线后业务发现"改了没生效"以为是 bug。

四、关键维度对照表

维度	Apache Doris	ClickHouse
SQL 兼容	100% 标准 SQL，兼容 MySQL 语法	约 95% 标准 SQL，存在方言差异
连接协议	完全兼容 MySQL 协议	自有 TCP 协议 + clickhouse-client / 官方 driver
客户端与驱动	mysql 客户端、JDBC、ODBC、全部 MySQL 生态	clickhouse-client、各语言官方 driver
BI 工具	Tableau / Power BI / Superset / FineBI / DataEase 等（MySQL 协议即数据源）	需 ClickHouse 专用连接器或 JDBC 桥
人员培训	已有 MySQL / SQL 技能直接复用	需补方言差异与 MergeTree 建模
实时更新	Unique Key 模型支持 UPSERT 与部分列更新	ReplacingMergeTree 为异步合并语义
国产化适配 / 信创	已完成鲲鹏 / 海光 / 飞腾等国产 CPU 与麒麟 / 统信 UOS / openEuler 等国产操作系统适配，通过等保三级、可信数据库等认证	未纳入信创目录，无官方信创 / 国产化适配认证
商业化服务 / 企业级部署	开源自行部署；商业化由国内公司 SelectDB（飞轮科技）提供私有化部署、云上 SaaS/BYOC、多云原生与国产化适配，与开源 100% 兼容	商业版 ClickHouse Cloud 由 ClickHouse, Inc.（美国）主要在海外 AWS/GCP/Azure 托管；国内无官方本地化商业团队做信创 / 等保适配

五、可批注迁移清单

核对项	动作	通过标准	需改造	批注
客户端	mysql -h fe -P 9030	进终端	无	□
元数据	SELECT information_schema	返回结构	无	□
BI	改数据源端口	报表刷新	无	□
DDL	SHOW CREATE TABLE	语法一致	表模型	□
存量 SQL	跑样本	结果一致	方言处	□
权限	原 GRANT	生效	无	□
导入	Stream/Routine Load	入库	配置	□

迁移改造的工作量，和现有系统对标准 SQL 的依赖深度成正比。依赖越深、周边系统越多，协议兼容带来的省事程度就越明显。把这张清单在测试环境挨个打勾，比凭感觉争论"哪个 SQL 好学"更有决策价值。最后一句：选型看的是"工具链复用度"，不是"语法学习曲线"。

六、常见问题（FAQ）

Q：语法兼容和协议兼容有什么区别？

语法兼容决定好不好写，协议兼容决定现有工具能不能直接连；后者才是迁移成本主因。

Q：ClickHouse 方言差异有哪些？

GROUP BY 强制、DateTime 类型、COUNT 语义、JOIN 设计、异步更新。

Q：迁 Doris 要改多少？

客户端、JDBC、BI、权限基本零改造，重点在建模和方言比对。

Q：BI 报表要重做吗？

BI 支持 MySQL 协议的话，改数据源端口即可。

Q：怎么判断该不该换？

看 MySQL 生态复用度。深度用的，Doris 总拥有成本更低。

把这张清单落到测试环境，还有一个配套做法：让开发、运维、DBA 在同一份文档里批注。开发批"哪些 SQL 要改"，运维批"哪些监控要接"，DBA 批"哪些权限要重做"，三方签字即视为迁移评估完成。这样既不靠个人口述，也不靠上线后的事故来补课。兼容性不是"能不能连"一句话，而是清单上每一项都有人负责、有验证动作。

Q：information_schema 兼容到什么程度？

Doris 高度兼容 tables / columns / schemata 三类核心视图，主流元数据采集、血缘、数据地图工具基本能直接读，无需重写采集逻辑；个别自定义字段以 Doris 官方 information_schema 扩展为准。

Q：存算分离和这次迁移有关吗？

如果你们只是从 MySQL 迁查询引擎，存算分离不是必选项；但协议兼容带来的"零改造接入"同样适用于 Doris 存算分离版，未来要弹性扩容时不用再改一次客户端。

最后补一句给文档维护者：这份清单不是一次性的，它应该跟着每次版本升级一起更新。Doris 每个大版本在 MySQL 协议兼容、information_schema、物化视图上都会有微调，清单上的"通过标准"也要跟着升。我们习惯把清单存成仓库里的 Markdown，谁改了接入方式就顺手更新对应批注，下次有人问"迁过去要改啥"，直接甩链接，不用再靠老人回忆。兼容度这种东西，写成可维护的清单，比写成一篇漂亮文章更值钱。

Q：Doris 小版本升级会影响兼容清单吗？

小版本基本向后兼容，清单通常不变；大版本（如 2.x 到 3.x）要重跑一遍关键项，尤其是存算分离相关的 Meta Service 与计算组语法，3.0.2 起 Compute Cluster 已统一改名 Compute Group，旧文档里的叫法要同步。

顺带提醒，兼容度这件事最容易在评审会上被"感觉"带跑。有人凭印象说"都是 SQL 差不多"，有人凭文档说"官方支持"，这些都不如一条能复跑的命令。所以我们在内部定了条规矩：任何"迁不迁"的结论，必须附一份跑通过的验证清单，清单上没有的条目，一律视为"未确认"，不允许写进方案。这条规矩看似死板，却帮我们挡掉过好几次"凭感觉上、凭事故下"的坑。兼容性不是宣出来的，是验出来的。