MySQL 26.7.0：日历版本号、Change Stream Applier 与线程池下放社区版
MySQL 在 7 月发布了 26.7.0（首个 Calendar Versioning 版本），随后 8 月 18 日出了 26.7.1（仅针对 Docker 镜像的 Critical Security Patch Update）。对 DBA 来说，这一版有两个「动了基础设施」的变化，值得认真看。
版本号变成日历格式：别被吓到
从 26.7.0 起，MySQL 用 年份.月份.Patch（YY.M.P）命名，26.7.0 = 2026 年 7 月 + 第 0 个补丁。这是 9.7 LTS 之后的第一个 Innovation 版本，也是新命名模型的首次落地。mysql_version.h 里加了 MYSQL_PREVIOUS_LTS_VERSION / MYSQL_PREVIOUS_LTS_VERSION_ID 来标明前一个 LTS（即 9.7.0，ID 90700），保证升级/降级路径清晰。
对绝大多数人，这只是命名习惯变了，功能上不用焦虑。关键提醒：别把 26.7 当成「大版本」来大动干戈，它就是季度节奏的 Innovation 线，下一发是 26.10.0。
Change Stream Applier（CSA）：复制执行架构换了
这是 26.7 最实打实的新东西。CSA 是复制 SQL applier 的新实现，作为 MTA（多线程 applier）之外、按通道（channel）可选的替代：
- 每个复制通道能独立配置 worker 数（1～1024），不再所有通道共享一套配置。订单库复制通道给 512 worker、分析库通道给 32 worker，资源隔离变现实。
- 接收线程和存储引擎接口不变，源端复制协议不用动，主从两端可以平滑切换。
对多通道、大延迟从库的架构，CSA 值得评估；单通道小规模复制，收益不明显，不必急着切。
线程池进社区版
Thread Pool 插件此前基本是企业版能力，现在进了 Community Edition。它的价值在高并发连接场景：避免线程-per-连接，减少上下文切换和 OS 调度压力。如果你的业务是几千上万的短连接、并发连接是瓶颈，这个值得测；一般 QPS 不高的库，收益有限，别为了新特性而开。
其他值得留意的点
- Undo 截断健壮性：截断进度现在写进 Undo Tablespace Header，不再依赖本地生成的 truncation 日志文件（旧文件仍兼容）。恢复路径更稳。
- 后量子密钥交换：用 OpenSSL 3.5+ 编译时支持 post-quantum 算法，等于是给未来加密标准铺路，短期不用管。
- 审计：
audit_log_file_count状态变量统计当前审计日志文件数，运维排查轮转/清理方便了。
要不要升
- 追求新能力、能按季度测试升级的：上 26.7.0。
- 求稳、要长期支持：继续 9.7 LTS 或 8.4 LTS（各自季度维护线，8.4 已到 8.4.11）。
- 还在 8.0 老线的：开始规划迁移到受支持的 LTS，别再拖。
一句话：26.7.0 不激进，是「复制架构换代 + 并发能力下放」的组合拳。CSA 和线程池都是按需启用的选项，不是默认行为——先看你的复制通道和并发场景值不值得，再决定切不切。