要是以后能实现单机分布式一体化就好了，这样做实验和测试就简单了
混一个积分:dog:
配置太高了没法安装群集
版本迭代的快是好事儿啊，说明产品一直在进化
外行领导内行
tiup playground 测试就行啊，非常简单。
1、ticdc可以用于不用版本tidb的同步吗，因为有两套，一套用于业务，一套用于数分。可以用数分提前升级验证新版本的性能等。
2、后面会有支持升级后回滚的功能吗？
3、看到一篇tiflash vs clickhouse的性能对比, 在4.0版本中tiflash有一定的性能差距，在7.0版本后，性能差距是咋样呢？
4、tidb7.0中，tiflash牺牲一定的性能换取整体分析查询的稳定性，这些牺牲的性能是否通过一些其他的优化补回来了呢？
性能调优方法论
TiCDC有像FlinkCDC一样进行全量和增量自动切换的能力吗？
这种需要扫描全表的，本身就没有太大优化空间。如果想有明显提升的，可以尝试下TiFlash，这种本身需要扫描全表的查询会有质的提升
目前不会~
TiDB 提供两个版本系列：
- 长期支持版本
- 开发里程碑版本（自 TiDB v6.0.0 起引入）
关于对 TiDB 版本提供支持服务的标准和规则，参见 TiDB 版本周期支持策略。
版本命名
TiDB 版本的命名方式为 X.Y.Z。X.Y 代表一个版本系列。
- 从 TiDB 1.0 起，
X每年依次递增，X 的递增代表引入新的功能和改进。 -
Y从 0 开始依次递增，Y 的递增代表引入新的功能和改进。 - 一个版本系列首次发版时
Z默认为 0，后续发补丁版本时Z从 1 开始依次递增。
TiDB v5.0.0 及其之前的版本命名规则，请查看历史版本。
长期支持版本
长期支持版本 (Long-Term Support Releases, LTS) 约每六个月发布一次，会引入新功能、改进、缺陷修复和安全漏洞修复。
LTS 命名方式为 X.Y.Z，Z 默认为 0。
示例版本:
- 6.1.0
- 5.4.0
在 LTS 生命周期内会按需发布补丁版本 (Patch Release)。补丁版本主要包含 bug 修复、安全漏洞修复，不会包含新的功能。
补丁版本命名方式为 X.Y.Z。其中，系列版本号 X.Y 与对应的 LTS 保持一致，补丁版本号 Z 从 1 开始依次递增。
示例版本:
- 6.1.1
注意
v5.1.0、v5.2.0、v5.3.0、v5.4.0 发布周期仅间隔两个月，但均为 LTS，提供对应补丁版本。
开发里程碑版本
开发里程碑版本 (Development Milestone Releases, DMR) 约每两个月发布一次。如遇 LTS 发版，DMR 发版时间顺延两个月。DMR 会引入新的功能、改进和修复。但 TiDB 不提供基于 DMR 的补丁版本，如有相关 bug 会在后续版本系列中陆续修复。
DMR 命名方式为 X.Y.Z，Z 默认为 0，并添加后缀 -DMR。
示例版本:
- 6.0.0-DMR
tidb为啥版本更新这么快~
技术大牛多，
有国际视野，
用户群驱动，
社区活跃高，
项目上漏洞扫描因mysql数据库版本低而不通过，目前除了通过 TiDB 配置文件中的 [server-version]配置项来修改 server 版本号避开漏洞扫描不通过外，是否还有其它方法？
OOM问题或者负载飙升问题，通常情况下是因为大SQL触发，你们在使用过程有没有对这类大资源SQL做好实时监控、定期review和不断优化（SQL优化或优化业务）呢？
我们这边使用前期也有不少类似的问题，但是经过一番管理优化后，稳定运行好多年了
GPT版本的表妹 
有呀，要是tidb能增加类似clickhouse的agg数据能力就好了
商业版和社区版主要有哪些区别？
tidb最佳实践参数
ticdc相较于binlog同步问题多吗？