本文字数：9448；估计阅读时间：24 分钟
作者：Alexey Milovidov
本文在公众号【ClickHouseInc】首发
转眼又到年末，意味着我们在 2025 年共完成了 12 个版本的发布。我想借此机会，回顾一下今年我最喜欢的一些新特性。
2025 年发布的 ClickHouse 各版本共计引入了 277 项新功能 🦃、319 项性能优化 ⌚ 以及 1051 个 bug 修复 🍄。
你可以通过以下链接查看每个版本的发布日志：
25.1、25.2、25.3 LTS、25.4、25.5、25.6、25.7、25.8 LTS、25.9、25.10、25.11。
至于 25.12 的发布博客，将在 2026 年初上线，敬请期待！
欢迎新贡献者
热烈欢迎所有在 2025 年加入 ClickHouse 的新贡献者！社区的持续壮大令人振奋，衷心感谢每一位为 ClickHouse 流行度做出贡献的朋友。
以下是今年新增的贡献者名单：
0xgouda, AbdAlRahman Gad, Agusti Bau, Ahmed Gouda, Albert Chae, Aleksandr Mikhnenko, Aleksei Bashkeev, Aleksei Shadrunov, Alex Bakharew, Alex Shchetkov, Alexander Grueneberg, Alexei Fedotov, Alon Tal, Aly Kafoury, Amol Saini, Andrey Nehaychik, Andrey Volkov, Andrian Iliev, Animesh, Animesh Bilthare, Antony Southworth, Arnaud Briche, Artem Yurov, Austin Bonander, Bulat Sharipov, Casey Leask, ChaiAndCode, Cheryl Tuquib, Cheuk Fung Keith (Chuck) Chow, Chris Crane, Christian Endres, Colerar, Damian Maslanka, Dan Checkoway, Danylo Osipchuk, Dasha Wessely, David E. Wheeler, David K, DeanNeaht, Delyan Kratunov, Denis, Denis K, Denny [DBA at Innervate], Didier Franc, Diskein, Dmitry Novikov, Dmitry Prokofyev, Dmitry Uvarov, Dominic Tran, Drew Davis, Dylan, Elmi Ahmadov, Engel Danila, Evgenii Leko, Felix Mueller, Fellipe Fernandes, Fgrtue, Filin Maxim, Filipp Abapolov, Frank Rosner, GEFFARD Quentin, Gamezardashvili George, Garrett Thomas, George Larionov, Giampaolo Capelli, Grant Holly, Greg Maher, Grigory Korolev, Guang, Guang Zhao, H0uston, Hans Krutzer, Harish Subramanian, Himanshu Pandey, Huanlin Xiao, HumanUser, Ilya Kataev, Ilya fanyShu, Isak Ellmer, Ivan Nesterov, Jan Rada, Jason Wong, Jesse Grodman, Jia Xu, Jimmy Aguilar Mena, Joel Höner, John Doe, John Zila, Jony Mohajan, Josh, Joshie, Juan A. Pedreira, Julian Meyers, Julian Virguez, Kai Zhu, Kaviraj, Kaviraj Kanagaraj, Ken LaPorte, Kenny Sun, Konstantin Dorichev, KovalevDima, Krishna Mannem, Kunal Gupta, Kyamran, Leo Qu, Lin Zhong, Lonny Kapelushnik, Lucas Pelecq, Lucas Ricoy, Luke Gannon, László Várady, Manish Gill, Manuel, Manuel Raimann, Mark Roberts, Marta Paes, Maruth Goyal, Max Justus Spransy, Melvyn Peignon, Michael Anastasakis, Michael Ryan Dempsey, Michal Simon, Mikhail Kuzmin, Mikhail Tiukavkin, Mishmish Dev, Mithun P, Mohammad Lareb Zafar, Mojtaba Ghahari, Muzammil Abdul Rehman, NamHoaiNguyen, Narasimha Pakeer, Neerav, Nick, Nihal Z., Nihal Z. Miaji, Nikita Vaniasin, Nikolai Ryzhov, Nikolay Govorov, NilSper, Nils Sperling, Oleg Doronin, Olli Draese, Onkar Deshpande, ParvezAhamad Kazi, Patrick Galbraith, Paul Lamb, Pavel Shutsin, Pete Hampton, Philip Dubé, Q3Master, Rafael Roquetto, Rajakavitha Kodhandapani, Raphaël Thériault, Raufs Dunamalijevs, Renat Bilalov, RinChanNOWWW, Rishabh Bhardwaj, Roman Lomonosov, Ronald Wind, Roy Kim, RuS2m, Rui Zhang, Sachin Singh, Sadra Barikbin, Sahith Vibudhi, Saif Ullah, Saksham10-11, Sam Radovich, Samay Sharma, Sameer Tamsekar, San Tran, Sante Allegrini, Saurav Tiwary, Sav, Sergey, Sergey Lokhmatikov, Sergio de Cristofaro, Shahbaz Aamir, Shakhaev Kyamran, Shankar Iyer, Shaohua Wang, Shiv, Shivji Kumar Jha, Shreyas Ganesh, Shruti Jain, Somrat Dutta, Spencer Torres, Stephen Chi, Sumit, Surya Kant Ranjan, Tanin Na Nakorn, Tanner Bruce, Taras Polishchuk, Tariq Almawash, Todd Dawson, Todd Yocum, Tom Quist, Vallish, Vico.Wu, Ville Ojamo, Vlad Buyval, Vladimir Baikov, Vladimir Zhirov, Vladislav Gnezdilov, Vrishab V Srivatsa, Wudidapaopao, Xander Garbett, Xiaozhe Yu, Yanghong Zhong, YjyJeff, Yunchi Pang, Yutong Xiao, Zacharias Knudsen, Zakhar Kravchuk, Zicong Qu, Zypperia, abashkeev, ackingliu, albertchae, alburthoffman, alistairjevans, andrei tinikov, arf42, c-end, caicre, chhetripradeep, cjw, codeworse, copilot-swe-agent[bot], craigfinnelly, cuiyanxiang, dakang, ddavid, demko, dollaransh17, dorki, e-mhui, f.abapolov, f2quantum, felipeagfranceschini, fhw12345, flozdra, flyaways, franz101, garrettthomas, gvoelfin, haowenfeng, haoyangqian, harishisnow, heymind, inv2004, jemmix, jitendra1411, jonymohajanGmail, jskong1124, kirillgarbar, krzaq, lan, lomik, luxczhang, mekpro, mkalfon, mlorek, morsapaes, neeravsalaria, nihalzp, ollidraese, otlxm, pheepa, polako, pranav mehta, r-a-sattarov, rajatmohan22, randomizedcoder dave.seddon.ca@gmail.com, restrry, rickykwokmeraki, rienath, romainsalles, roykim98, samay-sharma, saurabhojha, sdairs, shanfengp, shruti-jain11, sinfillo, somrat.dutta, somratdutta, ssive7b, sunningli, talmawash, tdufour, tiwarysaurav, tombo, travis, wake-up-neo, wh201906, wujianchao5, xander, xiaohuanlin, xin.yan, yahoNanJing, yangjiang, yanglongwei, yangzhong, yawnt, ylw510, zicongqu, zlareb1, zouyunhe, |2ustam, Андрей Курганский, Артем Юров, 思维
我最近在 ClickHouse 旧金山 Meetup 上分享了这些我最钟爱的功能 —— 你也可以查看此次分享的幻灯片资料（https://presentations.clickhouse.com/2025-meetupsf-3/top_features/#23）。
接下来是我今年最喜欢的功能精选。
轻量级更新（Lightweight Updates）
标准 SQL 的 UPDATE 语句，即“轻量级更新”功能，是在 ClickHouse 25.7 中引入的。
该功能基于一种轻量的 patch part 机制实现。与传统变更（classic mutations）不同，后者需要重写整个列的数据，而轻量更新只写入极小的“补丁片段”，可以快速生效，对查询性能几乎没有影响。
现在，如果我们需要更新某一行数据，只需使用一条标准 SQL 语句即可完成。
UPDATE orders SET discount = 0.2 WHERE quantity >= 40;在底层，ClickHouse 会插入一个极小的 patch part，这个补丁会在后续数据合并过程中生效，只更新实际变动的数据。
由于合并操作本身就会在后台持续运行，这些 patch parts 会自动在合并时生效，从而高效更新底层数据。
更新结果几乎实时可见 —— 即便 patch parts 尚未完成合并，它们也会被精准地匹配并按数据范围独立生效，确保在不干扰并行执行的前提下完成更新。
同样，你也可以使用标准 SQL 语法删除数据：
DELETE FROM orders WHERE order_id = 1001 AND item_id = 'mouse';ClickHouse 会创建一个将 `_row_exists` 字段标记为 0 的 patch part。待下次后台合并时，该行数据将被清除。
你可以在 ClickHouse 25.7 的发布博客中了解更多细节。如果你想进一步深入了解，推荐阅读 Tom Schreiber 撰写的三篇专题文章《ClickHouse 中的快速 UPDATE》：
第 1 部分：专用引擎
介绍 ClickHouse 如何通过插入驱动的引擎（如 ReplacingMergeTree、CollapsingMergeTree 和 CoalescingMergeTree）绕过传统的慢速行级更新。
第 2 部分：声明式 SQL 风格的 UPDATE
探讨我们如何利用 patch parts 以极低的成本实现标准 SQL 的 UPDATE 语法。
第 3 部分：基准测试
展示轻量级 UPDATE 的实际性能，我们测试了所有方案，包括声明式 UPDATE，性能提升最高可达 1000 倍。
🎁 彩蛋：ClickHouse vs PostgreSQL
我们还将 ClickHouse 的 SQL UPDATE 与 PostgreSQL 进行了正面对比。在相同硬件与数据条件下，ClickHouse 在批量更新中最多快了 4000 倍。
数据湖支持
近年来，我们持续观察到 Iceberg 和 Delta Lake 等开放表格式在数据生态中的快速普及。
ClickHouse 最早在 23.2 版本中就支持了对 Iceberg 表的直接查询，但随着 2024 年的推进，我们意识到，若要实现与这些表格式的深度集成，仅靠文件层是不够的，必须补全对 catalog 层（目录层）的全面支持。
因此，在整个 2025 年，我们大幅扩展了数据湖相关能力。这一年从支持 REST 和 Polaris 目录格式开始，到年底为止，ClickHouse 已陆续引入对以下主流目录系统的原生支持：
REST 和 Polaris 目录（自 24.12 起）
Unity catalog（自 25.3 起）
AWS Glue catalog（自 25.3 起）
Hive Metastore（自 25.5 起）
Microsoft OneLake（自 25.11 起）
从 24.11 到 25.8，ClickHouse 在数据湖功能上的演进堪称飞跃。下表展示了从最初的基本支持，到如今全面兼容开放表格式生态的过程。
文本索引（Text Index）
ClickHouse 对全文搜索的支持是一项长期工程。早在 2022 年，Harry Lee 与 Larry Luo 就启动了原型开发，并在 2023 年初步实现。但后续开发进展并不连续，历经反复迭代。
最终，这一功能被彻底重写，达到生产可用标准，并作为实验性功能于 25.9 版本推出，计划在 25.12 版本中晋升为 beta 阶段。
用户可通过以下方式为表中某列定义文本索引：
CREATE TABLE hackernews ( `id` Int64, `deleted` Int64, `type` String, `by` String, `time` DateTime64(9), `text` String, `dead` Int64, `parent` Int64, `poll` Int64, `kids` Array(Int64), `url` String, `score` Int64, `title` String, `parts` Array(Int64), `descendants` Int64, INDEX inv_idx(text) TYPE text(tokenizer = 'splitByNonAlpha') GRANULARITY 128 ) ORDER BY time;定义完成后，索引可加速使用下列文本函数的查询。
SELECT by, count() FROM hackernews WHERE hasToken(text, 'OpenAI') GROUP BY ALL ORDER BY count() DESC LIMIT 10;SELECT by, count() FROM hackernews WHERE hasAllTokens(text, ['OpenAI', 'Google']) GROUP BY ALL ORDER BY count() DESC LIMIT 10;SELECT by, count() FROM hackernews WHERE hasAnyTokens(text, ['OpenAI', 'Google']) GROUP BY ALL ORDER BY count() DESC LIMIT 10;我们在一个 50 TB 的日志数据集中对文本索引进行了测试，效果显著。如下动画对比了三种查询方式：无索引、布隆过滤器、文本索引，展示了它们在实际查询中的性能差异。
同时，下图展示了三种方式在大规模查询下的相对性能表现：
向量索引（Vector Index）
ClickHouse 向量搜索的实现经历了数年打磨。最初的实验版本出现在 22.9 版本，由 Arthur Filatenkov 等多位开发者协作实现。
在 23.8 版本，Davit Vardanyan 集成了 USearch 库，为平台带来了更完善的向量相似性搜索能力。
真正的性能突破出现在 2025 年。25.1 版本中，Shankar Iyer、Robert Schulze 和 Michael Kolupaev 对向量索引做了大幅优化；25.5 中加入了预过滤、后过滤与得分重排序等关键功能，使该特性首次具备生产可用性（beta）；而在 25.8 中，向量搜索正式进入 GA 阶段，引入仅索引读取、抓取倍数控制（fetch multiplier）与二值量化（binary quantization）等优化机制，进一步提升效率。
目前，ClickHouse 支持的近似向量搜索算法为 HNSW（Hierarchical Navigable Small World），一种广泛采用的高性能近似搜索算法，基于分层邻近图实现。
用户可以如下为某列创建向量索引：
CREATE TABLE wikiEmbeddings ( id Int32, title String, text String, url String, wiki_id Int32, views Float32, paragraph_id Int32, langs Int32, emb Array(Float32), INDEX emb_hnsw emb TYPE vector_similarity('hnsw', 'L2Distance', 768) ) ORDER BY id;随后，便可编写查询语句使用该索引：
WITH (SELECT emb FROM wikiEmbeddings WHERE id = 120356) AS lookup SELECT id, title, text, url, L2Distance(emb, lookup) AS dist FROM wikiEmbeddings ORDER BY dist LIMIT 3 FORMAT Vertical;另一个值得关注的进展是由 Raufs Dunamalijevs 引入的 QBit 数据类型。QBit 是一种面向向量嵌入的类型，支持在查询时动态调整精度。
可以为列定义 QBit 类型：
CREATE TABLE vectors ( id UInt64, name String, ... vec QBit(BFloat16, 1536) ) ORDER BY ();查询时则可指定使用高位的比特数，控制精度与性能的权衡：
SELECT id, name FROM vectors ORDER BY L2DistanceTransposed(vector, target, 10) LIMIT 10;查询条件缓存（Query Condition Cache）
ClickHouse 在 25.3 中引入了查询条件缓存机制，用于记录哪些 granule 范围满足 WHERE 子句的筛选条件，并在后续查询中重用这些信息，作为一种临时索引使用。
该机制在实际场景中极具价值，尤其适用于仪表盘、告警系统、交互式查询等经常反复执行相似 WHERE 条件的场景，亦包括在可观测性工作负载中对不断增长的数据进行过滤查询。
该缓存默认启用。在我们的实测中，该功能显著提升查询性能，达到数量级的加速效果。
SELECT count() FROM bluesky WHERE data.kind = 'commit' AND data.commit.operation = 'create' AND data.commit.collection = 'app.bsky.feed.post' AND data.commit.record.text LIKE '%????%'在对包含 1 亿行的 BlueSky 数据集执行如下查询时，首次运行耗时 0.481 秒；而启用查询条件缓存后，后续查询耗时仅为约 0.037 秒，性能提升超过 10 倍。
Join 顺序重排（Join Reordering）
在 ClickHouse 25.9 中，我们终于为广大用户带来了一个呼声已久的功能 —— 自动化的全局 Join 顺序重排（Join Reordering）。
该特性可以针对多个表之间的复杂 Join 图进行自动优化，支持的 Join 类型包括：内连接、左外连接、右外连接、交叉连接、半连接和反连接。其核心原理是利用 Join 操作在逻辑上具有结合律（associativity）这一特性，从而在执行层面优化 Join 顺序。
系统新增了两个设置项用于控制此功能：
query_plan_optimize_join_order_limit：设置参与自动重排的最大表数量
allow_statistics_optimize：允许在重排过程中参考统计信息进行优化
我们在 TPC-H 基准测试中选取了一个包含六张表的 Join 查询进行测试。结果令人惊喜：优化后的查询执行速度提升了约 1450 倍，内存使用量下降了近 25 倍。
如需了解更多实现细节，请参阅 25.9 版本的发布博客。
延迟读取与物化（Lazy Reading / Materialization）
ClickHouse 在 25.4 版本中引入了“延迟物化（lazy materialization）”功能，也常被称为“懒加载”。
该机制的核心思路是，在查询执行初期，系统不立即读取某列的实际数据，而是先追踪哪些数据“可能需要”被读取。当真正需要用到该列数据时，再执行读取操作。
在这一模式下，列数据可以在查询流程中被传递、参与过滤，但在执行管道的最终阶段之前，并不会参与计算逻辑。
我们对这一功能进行了实测：在一个查询中，我们试图找出 Amazon 评论中“获得最多有用投票”的前三条评论，并返回其标题、摘要和正文内容。
SELECT helpful_votes, product_title, review_headline, review_body FROM amazon.amazon_reviews ORDER BY helpful_votes DESC LIMIT 3 FORMAT Null;未开启延迟物化时，该查询耗时约 219 秒；启用该功能后，执行时间缩短至 0.14 秒，性能提升达 1576 倍。此外，I/O 操作减少了 40 倍，内存占用下降近 300 倍。
该功能对于包含大字段或延迟使用字段的大型分析型查询尤为有效，能够显著降低资源消耗并提升响应速度。
征稿启示
面向社区长期正文，文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出&图文并茂。质量合格的文章将会发布在本公众号，优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至：Tracy.Wang@clickhouse.com
