> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-mintlify-fbfa8bee.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 生产环境应使用哪个 ClickHouse 版本？

> 本页提供有关在生产环境中应使用哪个 ClickHouse 版本的指导

首先，我们先来讨论一下，为什么大家会提出这个问题。主要有两个原因：

1. ClickHouse 的开发迭代速度很快，通常每年会发布 10 个以上的稳定版本。可选的发行版很多，因此这并不是一个容易做出的选择。
2. 有些用户不想花时间判断哪个版本最适合自己的使用场景，而是希望直接参考别人的建议。

第二个原因更根本一些，因此我们先从这里说起，然后再回过头来看如何在各种 ClickHouse 发行版中进行选择。

<div id="which-clickhouse-version-do-you-recommend">
  ## 你推荐使用哪个 ClickHouse 版本？
</div>

人们很容易通过聘请顾问或听信一些知名专家的建议，来摆脱自己对生产环境的责任。你安装了别人推荐的某个特定 ClickHouse 版本；如果它出了问题——那就不是你的错，而是别人的错。这种想法是个巨大的陷阱。没有任何外部人士会比你更了解你公司生产环境中的实际情况。

那么，究竟该如何正确选择要升级到哪个 ClickHouse 版本？或者，该如何选择第一个要用的 ClickHouse 版本？首先，你需要投入精力搭建一个**贴近真实情况的预生产环境**。理想情况下，它可以是一个完全一致的影子副本，但这通常成本很高。

下面是一些关键点，可以帮助你以不算太高的成本，让预生产环境具备足够高的仿真度：

* 预生产环境需要运行尽可能接近你计划在生产环境中运行的那组查询：
  * 不要把它做成只读环境，只配一份静态数据。
  * 不要把它做成只写环境，只复制数据却不生成一些典型报表。
  * 不要用直接清空环境来代替应用 schema 迁移。
* 使用真实生产数据和查询的样本。尽量选择仍然具有代表性、并且能让 `SELECT` 查询返回合理结果的样本。如果你的数据比较敏感，且内部政策不允许其离开生产环境，请使用脱敏处理。
* 确保预生产环境和生产环境一样，纳入你的监控和告警系统覆盖范围。
* 如果你的生产环境横跨多个 datacenter 或区域，也要让你的预生产环境保持一致。
* 如果你的生产环境使用了复制、分布式表和级联 materialized view 等复杂特性，请确保它们在预生产环境中的配置也尽量相似。
* 预生产环境究竟是使用与生产环境大致相同数量但规格更小的服务器或 VM，还是使用少得多但规格相同的服务器或 VM，这之间需要权衡。前一种方案可能捕获更多与网络相关的问题，而后一种则更容易管理。

第二个值得投入的领域是**自动化测试基础设施**。不要认为某类查询成功执行过一次，就会永远持续成功。有一些对 ClickHouse 做 mock 的单元测试是可以的，但要确保你的产品具备一套合理的自动化测试，并且这些测试是在真实 ClickHouse 上运行的，用来检查所有重要用例是否仍按预期工作。

更进一步，你还可以把这些自动化测试贡献给 [ClickHouse 的开源测试基础设施](https://github.com/ClickHouse/ClickHouse/tree/master/tests)，这些测试会在其日常开发中持续运行。学习[如何运行它](/zh/resources/develop-contribute/contribute/tests)，以及之后如何让你的测试适配这个框架，肯定都需要额外的时间和精力，但这是值得的——这样一来，当某个 ClickHouse 发行版被宣布为稳定版本时，它实际上已经用这些测试验证过了，而不是你在事后一次次浪费时间报告问题，然后再等待 bug 修复被实现、回移并发布。有些公司甚至将“谁使用基础设施，谁就要为其贡献测试”作为内部政策 (Google 将其称为 [Beyonce's Rule](https://www.oreilly.com/library/view/software-engineering-at/9781492082781/ch01.html#policies_that_scale_well)) 。

当你已经具备预生产环境和测试基础设施后，选择最佳版本就很直接了：

1. 定期针对新的 ClickHouse 发行版运行你的自动化测试。即使是那些被标记为 `testing` 的 ClickHouse 发行版，你也可以这样做，但不建议继续推进后续步骤。
2. 将通过测试的 ClickHouse 发行版部署到预生产环境，并检查所有流程是否都按预期运行。
3. 将你发现的任何问题报告到 [ClickHouse GitHub Issues](https://github.com/ClickHouse/ClickHouse/issues)。
4. 如果没有发现重大问题，那么就可以安全地开始将该 ClickHouse 发行版部署到你的生产环境中。进一步投入渐进式发布自动化，并采用类似 [canary releases](https://martinfowler.com/bliki/CanaryRelease.html) 或 [green-blue deployments](https://martinfowler.com/bliki/BlueGreenDeployment.html) 的方法，可能会进一步降低生产环境中出现问题的风险。

你可能已经注意到，上述方法并没有什么是 ClickHouse 特有的——对于任何自己依赖的基础设施，只要认真对待生产环境，人们都会这样做。

<div id="how-to-choose-between-clickhouse-releases">
  ## 如何在 ClickHouse 发行版之间进行选择？
</div>

如果你查看 ClickHouse 软件包仓库的内容，会看到两类软件包：

1. `stable`
2. `lts` (长期支持)

下面是关于如何在两者之间进行选择的一些建议：

* `stable` 是我们默认推荐的包类型。它们大致按月发布 (因此能以相对合理的延迟提供新功能) ，并且我们为最新的三个稳定版本提供诊断支持和 bug 修复回移。
* `lts` 每年发布两次，自首次发布起支持一年。在以下情况下，你可能会更倾向于选择它，而不是 `stable`：
  * 你们公司有内部政策，不允许频繁升级或使用非 LTS 软件。
  * 你在某些次要产品中使用 ClickHouse，而这些产品要么不需要复杂的 ClickHouse 功能，要么没有足够的资源持续更新。

许多团队一开始认为 `lts` 是更合适的选择，但最终往往还是会转向 `stable`，因为某个对其产品很重要的新功能已经在近期发布。

<Tip>
  升级 ClickHouse 时还有一点需要注意：我们始终密切关注各个发行版之间的兼容性，但有时没有必要完全保持不变，因此某些细节可能会发生变化。所以升级前请务必查看[更新日志](/zh/resources/changelogs/oss/2026)，确认是否有关于向后不兼容变更的说明。
</Tip>