新建PolarDB for MySQL集群：8.0.1与8.0.2版本选择及例外场景

默认推荐版本：8.0.2 #

针对你这种OLTP为主、附带定期分析查询的全新集群场景，默认优先选8.0.2，核心实战判断依据：

• 混合负载适配性更强：8.0.1的并行查询能力仅针对简单场景优化，而8.0.2的查询引擎并行增强特性，在处理复杂统计分析查询时，能更智能地分配多核资源，既不会拖慢OLTP事务的响应速度，实测中复杂统计查询的耗时还能降低30%-50%。
• 存储分区能力更实用：8.0.2的分区修剪逻辑更智能，支持的分区类型也更丰富，对于有冷热数据分离需求的场景，不用额外开发就能通过分区策略降低存储成本；而8.0.1在大分区表的DML操作上容易出现锁等待，维护成本更高。
• 后续运维更省心：从阿里云实际运维节奏来看，8.0.2是当前主力维护版本，补丁更新、性能优化的频率远高于8.0.1，遇到问题后的响应和修复优先级也更高。

例外选择8.0.1的场景 #

只有在以下明确的实战场景中，才考虑选8.0.1：

• 依赖8.0.1专属兼容特性：如果业务代码里用到了仅8.0.1支持的特定语法、函数，或者依赖其独有的事务隔离级别行为，且短期内无法修改代码，只能选8.0.1。
• 极端稳定性优先的纯OLTP核心系统：如果你的业务是绝对不能出任何兼容性问题的核心交易系统，且完全没有分析查询需求，同时没有足够时间做8.0.2的全量测试，8.0.1因为推出更早，经过的大规模生产验证更多，极端场景下的稳定性记录更久（但后续建议计划升级到8.0.2）。

内容的提问来源于stack exchange，提问作者Andrew Zhao