MySQL 26.7.0 深度解析：CalVer 元年、Change Stream Applier 重写并行复制、线程池免费开放——数据库内核的一次范式迁移（2026 实战指南）

引子：一个「不按套路出牌」的版本号

2026 年 7 月 28 日，MySQL 官方发布了 26.7.0。第一次看到这个版本号的老 DBA 大概率会愣一下：MySQL 不是才走到 9.x 吗？哪来的 26.7？

这其实比任何单个新特性都更深远——MySQL 正式告别「主版本.次版本」的传统语义化版本体系，切换到日历版本（CalVer）。26.7 的含义是 2026 年 7 月，版本号本身就是时间轴。而 9.7 LTS 系列，成了最后一代传统版本号的守门员。

但如果你以为 26.7.0 只是换了个版本号，那就错了。这个版本里藏着三件大事：

1. Change Stream Applier（CSA）：复制应用层的一次重写，把多线程复制（MTA）从「全局一刀切」推向「按通道精细调度」；
2. 线程池（Thread Pool）免费开放：这个在 Enterprise 版里锁了十几年的性能组件，终于进了社区版；
3. TLS 1.3 后量子加密（PQC）：面向「先收割、后解密」威胁的密码学升级，一口气铺满主连接、管理连接、异步复制、Group Replication、X Plugin 五条通道。

这篇文章从版本体系、复制架构、并发模型、传输安全、存储引擎五个维度拆解 26.7.0，并给出完整的部署、配置与调优实战。全文所有事实均来自 MySQL 官方 26.7.0 Release Notes 与 Reference Manual，代码可直接复制到你的环境验证。

一、背景：版本体系变革，CalVer 元年

1.1 为什么 MySQL 要换版本号

MySQL 的版本号历史有多混乱，老运维都懂：5.5 → 5.6 → 5.7 小版本号挤了十几年，8.0 一口气跳了两个大版本，随后又是 8.1、8.2……8.4 这种「年度创新版」，再后来 9.0、9.1，直到 9.7 LTS。版本号完全无法承载「这个版本是什么时候出的、支不支持长期维护」这两条最关键的信息。

Oracle 的解法是向 Linux 发行版和编程语言社区靠拢：用发布年月做版本号。官方 Release Notes 写得很直白：

MySQL Server now uses calendar-based versioning for releases after the 9.7 LTS series. Version values use Year.Month.Patch (YY.M.P) format. MySQL 26.7.0 is the first such calendar-version release.

也就是说：9.7 LTS 之后，所有新版本都走 YY.M.P 格式。26.7.0 = 2026 年 7 月的第 0 个补丁版本。以后看到 26.10 就知道是 2026 年 10 月，看到 27.1 就知道是 2027 年 1 月——版本号第一次变得「可预测」。

1.2 对升级路径的硬约束：mysql_version.h 的暗线

为了给升级/降级路径提供程序化依据，官方在 mysql_version.h 里新增了两个宏：

/* mysql_version.h (26.7.0) */
#define MYSQL_PREVIOUS_LTS_VERSION     "9.7.0"   /* 上一个 LTS 版本号 */
#define MYSQL_PREVIOUS_LTS_VERSION_ID  90700     /* 9.7.0 的数字编码 */

这套「版本谱系」直接落到了 Clone 插件上。26.7.0 的 Clone 规则完全按 CalVer/LTS 谱系重写（WL #17317）：

• 版本字符串完全一致 → 允许 Clone；
• 同一版本号的不同补丁版本（如 26.7.0 → 26.7.1）→ 允许；
• 一个 LTS → 下一个 LTS（如 9.7 → 26.7）→ 允许；
• 一个 LTS → 更老的 LTS → 禁止；
• 一个 LTS → 更晚但不是相邻的 LTS → 禁止；
• 只要有一方不是 LTS，且主/次版本号不匹配 → 禁止。

翻译成人话：Clone 的兼容矩阵从「版本字符串比对」升级成了「LTS 谱系比对」。这意味着跨大版本做 Clone 迁移（比如 9.7 LTS 直接 Clone 到 26.7 LTS）第一次有了官方支持，而不必先原地升级再 Clone。对大规模物理迁移场景，这能省掉一整轮「先升后迁」的中间态。

1.3 对存量用户意味着什么

• 还在 5.7 的：5.7 早已 EOL，26.7 的文档里连 5.7 的痕迹都很少了，请务必经由 8.0/8.4 → 9.7 的路径逐步上来；
• 在 8.0/8.4 的：8.4 是 LTS，仍受支持；但新功能（CSA、PQC）只会在 26.x 系列出现，8.4 只会收安全补丁；
• 在 9.x 创新版的：9.7 是最后的传统版本号 LTS，也是通往 CalVer 的桥梁，建议把 9.7 作为跳板版本规划升级窗口。

二、核心概念：复制架构的 25 年演进

要理解 CSA 的价值，得先看清楚 MySQL 复制是怎么一步步走到今天的。

2.1 从异步到半同步到组复制

• 2000 年（3.23.15）：引入 Replication，单线程，从库拉取事件直接回放，没有 relay log；
• 2002 年（4.0.2）：从库拆出 IO 线程与 SQL 线程，引入 relay log，主备解耦；
• 2010 年（5.5）：半同步复制（semi-sync），主库提交前至少等一个从库收到 relay log；
• 2016 年（5.7.17）：InnoDB Group Replication，基于 Paxos 的组复制，全同步协议；
• 2018 年（8.0）：Group Replication 正式 GA，writeset 依赖检测上线，并行复制能力大幅提升。

复制协议 25 年没变的核心资产是 binlog 事件流 + relay log + 回放线程，变的只是「谁来回放、怎么并行」。

2.2 并行复制的三次进化

从库回放是单线程的，主库却是多线程提交的——这是主从延迟的根源。MySQL 的解法一路演进：

1. DATABASE 级并行（5.6）：不同库的事务分给不同 worker。粒度太粗，一个库就废了；
2. LOGICAL_CLOCK 级并行（5.7）：基于组提交（group commit）的 last_committed/sequence_number，同一组提交的事务可以并行回放。粒度到事务，但依赖组提交窗口；
3. Writeset 并行（8.0）：通过收集事务写集（Writeset）判断事务间是否真的存在行级冲突，没有冲突就允许并行，哪怕它们不在同一提交组。这是目前 MTA（Multi-Threaded Applier）的默认形态。

2.3 MTA 的四宗罪

MTA 解决了「能不能并行」的问题，但它的工程实现有四个硬伤，在大规模、多业务混部场景下尤其明显：

1. 全局配置一刀切：replica_parallel_workers 是全局变量，所有通道共用一份。一个通道需要 32 个 worker，另一个通道只需要 4 个？做不到，要么全 32 要么全 4；
2. 应用与提交强耦合：worker 按依赖顺序应用事务，但提交阶段必须严格按提交序（commit ordering）执行。一旦某个事务因为锁等待暂时无法提交，这个 worker 就空转等待，后面的并行度全部归零——这就是经典的「并行应用、串行提交」瓶颈；
3. relay log 清理粒度粗：relay log 文件的清理依赖所有消费者都读完，MTA 下事件内存缓存与回放进度耦合，容易导致 relay log 堆积；
4. 通道之间互相拖累：一个通道报错或执行 STOP REPLICA，其他通道跟着遭殃；错误恢复也缺乏通道级隔离。

CSA 就是冲着这四宗罪来的。

三、架构分析：Change Stream Applier（CSA）

3.1 它是什么

官方定义：CSA 是多线程复制的新版 SQL 应用器实现，是 MTA 的 opt-in、按通道（per-channel） 的替代品（WL #10500）。它不改变源端协议、不改变 CHANGE REPLICATION SOURCE TO 的命令体系、不改变 relay log 格式，接收线程和存储引擎接口全部保持不变——也就是说，你不需要动主库，也不需要重搭从库，就能在从库侧切换到 CSA。

3.2 五大架构设计点

① 按通道配置，worker 数 1~1024

CSA 把应用器的配置从「全局」下沉到「通道」。新增三个通道选项：

CHANGE REPLICATION SOURCE TO
  APPLIER_VERSION = 2,                    -- 1=MTA(默认)  2=CSA
  APPLIER_WORKER_COUNT = 8,               -- 每个通道 1~1024 个 worker
  APPLIER_EVENT_MEMORY_LIMIT = 1073741824 -- 每个通道 binlog 事件缓存上限(字节)
FOR CHANNEL 'orders_channel';

• APPLIER_VERSION=1 是 MTA，新通道默认值；=2 切到 CSA；
• APPLIER_WORKER_COUNT 只对 CSA 生效，范围 1~1024。不指定时回退用全局 replica_parallel_workers；
• APPLIER_EVENT_MEMORY_LIMIT 是 CSA 的通道级事件缓存上限，默认 0。注意：有效下限是 replica_max_allowed_packet，配置值低于它会告警并按下限生效。

② 应用与提交解耦（最关键的设计）

MTA 下 worker 遇到「暂时不能提交」的事务只能空等；CSA 则把事务应用和提交排序拆成两个阶段：当一个 worker 无法立即提交当前事务时，它可以转身去应用另一个**依赖已就绪（dependency-ready）**的事务，而不是把 CPU 让给空气。这相当于给回放流水线加了「乱序执行 + 提交重排」，类似 CPU 的 OoO（Out-of-Order Execution）思想——只要最终提交序严格一致，中间怎么穿插都行。

③ 并行读 relay log + 事件内存按需释放

CSA 支持并行读取 relay log 里的事务，并且事件缓存是「消费即释放」的：事务被 worker 拿走应用后，对应的事件内存立即归还。这解决了大事务场景下从库内存被 relay log 事件撑爆的老问题。

④ relay log 精细化清理

MTA 时代 relay log 的清理条件是「所有消费者都读完」。CSA 引入多消费者感知的清理策略：一个 relay log 文件只有在所有消费者都成功完成、且前面所有 relay log 文件都具备清理资格时才会被 purge；某个消费者失败时，它需要的文件会被保留，且阻止后面文件的清理。这避免了「清理过头导致回放断档」和「清理不掉导致磁盘暴涨」两个极端。

⑤ 通道级故障隔离 + 更好的 STOP 响应

CSA 通道遇到错误时，其他通道继续运行，不会整个从库停摆；STOP REPLICA 的响应速度也明显改善。同时，CSA 的配置与 worker 状态全部通过 Performance Schema 暴露，可观测性比 MTA 的 SHOW REPLICA STATUS 单点视图强一个量级。

3.3 限制矩阵：什么场景不能用 CSA

CSA 很强大，但约束也硬，官方列得明明白白：

结论：CSA 是「新一代 GTID + ROW 格式复制」的专属应用器。还在用文件位点、statement 格式、延迟复制的老架构，要么先改造，要么继续用 MTA。

3.4 迁移路径

• 新通道：直接在建通道时 APPLIER_VERSION=2 即可，零成本；
• 存量通道：必须先停 SQL 线程，再改配置，再启动：

STOP REPLICA SQL_THREAD FOR CHANNEL 'orders_channel';
CHANGE REPLICATION SOURCE TO
  APPLIER_VERSION = 2,
  APPLIER_WORKER_COUNT = 16,
  APPLIER_EVENT_MEMORY_LIMIT = 2147483648
FOR CHANNEL 'orders_channel';
START REPLICA SQL_THREAD FOR CHANNEL 'orders_channel';

切换是在线的：接收线程不用停，binlog 不会断流，只是应用器实现热切换。

3.5 CSA vs MTA 对比一览

一句话总结：MTA 是「全局线程池 + 串行提交」，CSA 是「每通道调度器 + 乱序应用 + 有序提交」。前者是 8.0 时代的答案，后者是 26.x 时代的地基。

四、架构分析：线程池开放——社区版等了十几年的组件

4.1 线程池是什么

默认 MySQL 是 connection-per-thread 模型：每个客户端连接一个线程。连接数一多（几千上万），线程上下文切换和栈内存（默认 1MB/线程）就把 CPU 和内存吃光了。

线程池（Thread Pool Plugin）把模型改成 N 个 worker 线程服务 M 个连接：

• Listener 线程：负责 accept 新连接；
• Worker 线程：从队列取任务执行，默认 thread_pool_size 个组（一般 = CPU 核数）；
• Timer 线程：监控 worker 是否「卡死」（stall detection），超过 thread_pool_stall_limit（默认 200ms）就临时加线程，防止一个慢查询饿死整个池子。

它的核心价值是：连接数可以很高，但活跃线程数被钉在 CPU 核数附近，高连接低并发场景下吞吐和稳定性都远超 connection-per-thread。

4.2 26.7.0 的变化

官方 Release Notes 只有一句话，但分量极重：

MySQL Thread Pool plugin, formerly only available in MySQL Enterprise Edition, is now available in MySQL Community Edition 26.7.0. (WL #17296)

Thread Pool 从 Enterprise 专属变为社区版可用。 这是社区版多年来呼声最高的组件之一——过去只能用 Percona/MariaDB 的变体，或者靠 thread_handling=pool-of-threads 在特定构建里碰运气，现在官方社区版直接给。

同时默认值也调了：thread_pool_max_unused_threads 从 2 改为 32（Bug #39405207）。这个变量控制线程池保留的最大空闲线程数。老默认值 2 在突发流量下要频繁建线程（建线程是要加锁、要分配栈的），32 意味着池子常态保留更多热线程，突发时延更低——代价是空闲时多占几十 MB 内存，对现代服务器可以忽略。

4.3 什么时候该用、什么时候别用

推荐启用：

• 连接池配置过大（如 500+ 连接常驻）的 Java/PHP 应用；
• 短连接风暴场景（连接频繁建立/销毁）；
• 高连接但单连接低并发的 OLTP 混部。

不建议启用：

• 单连接跑重型分析查询（大 JOIN、大排序），线程池的 stall 机制会反复加线程，反而抖动；
• 对查询延迟极敏感、连接数本来就低的场景——线程池会引入排队延迟。

五、架构分析：TLS 1.3 后量子加密（PQC）

5.1 为什么要现在做

「先收割，后解密」（Harvest Now, Decrypt Later）：攻击者现在把加密流量全部存下来，等量子计算机成熟后再批量解密。数据库的复制链路、管理链路传输的都是核心数据，现在不升级密钥交换，未来就是裸奔。所以 MySQL 在 26.7.0 直接给 TLS 1.3 接入了 PQC（要求 OpenSSL 3.5.0+，WL #17245）。

5.2 变量体系：五条通道 × 三类开关

PQC 支持覆盖五条 TLS 通道：主连接、管理连接（admin）、异步复制、Group Replication 恢复、X Plugin。每类通道三组变量：

① 强制开关（force_pqc）：只接受 PQC 兼容密钥交换组协商的 TLS 连接

[mysqld]
force_pqc = ON                    # 主连接强制 PQC
admin_force_pqc = ON              # 管理连接
replication_force_pqc = ON        # 异步复制
group_replication_force_pqc = ON  # 组复制恢复
mysqlx_force_pqc = ON             # X Plugin

② 密钥交换组（tls_kex）：指定使用的 TLS 密钥交换组（含混合 classical/PQC 组，如 ML-KEM 与 X25519 的组合）

tls_kex = X25519MLKEM768          # 混合组示例
replication_tls_kex = X25519MLKEM768

③ 签名算法（use_pqc_sign）：是否在握手时宣告 PQC 签名算法（如 ML-DSA）；关闭则只宣告经典算法。注意：若开启但 OpenSSL 不支持 PQC，则回退 OpenSSL 默认行为。

use_pqc_sign = ON
replication_use_pqc_sign = ON

配套新增状态变量用于观测当前连接实际协商结果：Tls_key_exchange_algorithm（当前连接协商的密钥交换组）、Tls_sign_algorithm（当前连接协商的签名算法），以及 X Plugin 通道的有效配置回显 Mysqlx_force_pqc、Mysqlx_tls_kex、Mysqlx_use_pqc_sign。

5.3 部署注意

• 需要 OpenSSL 3.5.0+，否则 PQC 相关配置不生效（会静默回退）；
• 建议先开 use_pqc_sign / tls_kex 观察、再开 force_pqc：先让链路协商到 PQC 组并确认 Tls_key_exchange_algorithm 状态变量符合预期，再强制，避免老客户端全部连不上；
• 复制链路强制 PQC 时，主从两端都要升级到 26.7 + OpenSSL 3.5，混布版本会握手失败。

六、架构分析：InnoDB 与优化器的「暗线」更新

除了三件大事，26.7.0 还埋了不少值得注意的底层变化。

6.1 undo truncation log 正式退役

以前 InnoDB 做 undo 表空间的创建/截断，要依赖本地的 undo truncate log 文件记录进度。26.7.0 起（WL #16989 / WL #17187），截断进度直接写进 Undo Tablespace 头，不再生成新的 truncate log 文件。老文件仍然兼容，但不会再有新的。

好处：少一类文件、少一层崩溃恢复时的文件校验，undo 管理更干净。坏处：从旧版本降级/回滚到 26.7 之前的版本时，要确认没有进行中的 undo 截断。

6.2 两个来自中国团队的贡献

• 腾讯（Kaiwang Chen 团队）：修复 ReadView 的 false sharing。ReadView 通过 intrusive list 共享，原实现硬编码 64 字节 cache line 计算 padding，在非 64 字节缓存行的 CPU 上隔离失效，事务线程与 purge 线程争抢同一缓存行。现在按平台实际 cache line 保留 padding（Bug #116878 / #37569394）；
• 阿里（Huaxiong Song 团队）：修复对已有表新增 AUTO_INCREMENT 列时，部分记录被跳过导致自增值不准的问题（Bug #115136 / #37105825）。

这两类贡献说明 MySQL 内核的「多核缓存一致性」和「边界 DDL」打磨仍在继续——都是生产环境踩过的坑。

6.3 超图优化器（Hypergraph Optimizer）继续补课

• SELECT DISTINCT ... LIMIT：之前物化去重会处理完全部行再 LIMIT，现在把 LIMIT 下推给去重过程，找到足够多的唯一行就停（Bug #36720017）；
• 低 LIMIT 的 hash join：之前可能做无谓的磁盘 spill，现在会同时考虑内存/落盘两种计划按成本选（Bug #36684053）；
• BETWEEN 常量边界：识别为精确范围扫描，去掉多余 filter（Bug #37152269）；
• 物化派生表：把临时索引构建成本计入计划选择（Bug #36957877）。

这些都是超图优化器从「能用」走向「好用」的补课，如果你在用 optimizer_switch=hypergraph_optimizer=on，升级后 EXPLAIN 结果可能会有惊喜变化。

6.4 其他值得知道的

• mysqldump 新增 --extended-insert-multiline：配合 --extended-insert，每行数据单独一行，diff 更友好（Bug #112719）；
• 审计日志新增 audit_log_file_count 状态变量（WL #17292）；
• group_replication_communication_stack 默认值从 XCOM 改为 MYSQL（WL #15709），且与 group_replication_ip_allowlist 一起被标记废弃（WL #17300）——组复制的通信栈在向更简化的方向收敛；
• 升级性能优化：mysql.general_log / mysql.slow_log 的升级 ALTER TABLE 被精简（阿里 Karry Zhang 团队贡献）。

七、代码实战：从零部署 26.7.0 并启用 CSA

7.1 部署（Docker 示例）

# 拉取 26.7.0 社区版镜像并启动主库
docker run -d --name mysql267-master \
  -e MYSQL_ROOT_PASSWORD=rootpass \
  -p 3306:3306 \
  mysql:26.7.0 \
  --server-id=1 \
  --log-bin=mysql-bin \
  --binlog-format=ROW \
  --gtid-mode=ON \
  --enforce-gtid-consistency=ON \
  --binlog-transaction-compression=ON

# 从库（server-id=2，预留 8 个 CSA worker 的连接能力）
docker run -d --name mysql267-replica \
  -e MYSQL_ROOT_PASSWORD=rootpass \
  -p 3307:3306 \
  mysql:26.7.0 \
  --server-id=2 \
  --gtid-mode=ON \
  --enforce-gtid-consistency=ON \
  --read-only=ON \
  --super-read-only=ON \
  --replica-parallel-workers=8

7.2 初始化 GTID 复制

-- 从库上执行
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='mysql267-master',
  SOURCE_PORT=3306,
  SOURCE_USER='repl',
  SOURCE_PASSWORD='replpass',
  SOURCE_AUTO_POSITION=1
FOR CHANNEL 'orders_channel';

START REPLICA FOR CHANNEL 'orders_channel';

-- 确认状态
SHOW REPLICA STATUS FOR CHANNEL 'orders_channel'\G
-- 关注: Replica_IO_Running: Yes / Replica_SQL_Running: Yes
--       Retrieved_Gtid_Set / Executed_Gtid_Set

7.3 在线切换通道到 CSA

-- 新通道直接建 CSA：
-- CHANGE REPLICATION SOURCE TO APPLIER_VERSION=2, ... FOR CHANNEL 'x';

-- 存量通道：先停 SQL 线程，再切换，再启动
STOP REPLICA SQL_THREAD FOR CHANNEL 'orders_channel';

CHANGE REPLICATION SOURCE TO
  APPLIER_VERSION = 2,
  APPLIER_WORKER_COUNT = 16,               -- 每通道 16 个 worker
  APPLIER_EVENT_MEMORY_LIMIT = 2147483648  -- 2GB 事件缓存
FOR CHANNEL 'orders_channel';

START REPLICA SQL_THREAD FOR CHANNEL 'orders_channel';

7.4 用 Performance Schema 观测 CSA

-- 通道级应用器状态（含 CSA 配置生效值）
SELECT * FROM performance_schema.replication_applier_status\G

-- 每个 worker 的实时状态：正在应用哪个事务、等待什么
SELECT WORKER_ID, APPLYING_TRANSACTION, APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP,
       APPLYING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP, LAST_APPLIED_TRANSACTION
FROM performance_schema.replication_applier_status_by_worker
WHERE CHANNEL_NAME = 'orders_channel';

-- 通道连接/接收状态
SELECT * FROM performance_schema.replication_connection_status
WHERE CHANNEL_NAME = 'orders_channel'\G

-- 结合 sys 库看复制延迟（秒）
SELECT CHANNEL_NAME, APPLYING_TRANSACTION,
       TIMESTAMPDIFF(SECOND, APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP, NOW()) AS lag_seconds
FROM performance_schema.replication_applier_status_by_worker;

MTA 时代你只能靠 SHOW REPLICA STATUS 的 Seconds_Behind_Source 这一个标量；CSA 时代你能看到每个 worker 正在处理哪个事务、原始提交时间是多少——延迟定位从「黑盒」变成「白盒」。

7.5 启用线程池

-- 安装线程池插件（26.7 社区版可用）
INSTALL PLUGIN thread_pool SONAME 'thread_pool.so';

-- 查看生效配置
SHOW VARIABLES LIKE 'thread_pool%';
-- thread_pool_size            = 16        (建议 = CPU 核数)
-- thread_pool_max_unused_threads = 32     (26.7 新默认)
-- thread_pool_stall_limit     = 200       (ms)

-- 生产建议：写进 my.cnf 而非运行时 SET GLOBAL

[mysqld]
plugin-load-add=thread_pool.so
thread_pool_size=16
thread_pool_max_unused_threads=32
thread_pool_stall_limit=200

注意：thread_pool_size 修改后要重启才生效；连接数小于池子容量时线程池退化为近似直连，基本无感。

7.6 启用 PQC TLS（先观测后强制）

[mysqld]
# 第一步：只宣告、只协商，不断连
use_pqc_sign = ON
tls_kex = X25519MLKEM768

# 第二步：确认 Tls_key_exchange_algorithm 后，再强制
# force_pqc = ON
# replication_force_pqc = ON

-- 观测当前连接实际协商结果
SHOW STATUS LIKE 'Tls_key_exchange_algorithm';
SHOW STATUS LIKE 'Tls_sign_algorithm';
-- Tls_key_exchange_algorithm | X25519MLKEM768   ← 已走混合 PQC 组
-- Tls_sign_algorithm         | MLDSA65           ← 已用 PQC 签名

7.7 新工具选项尝鲜

# 每行一条 INSERT，diff/评审友好
mysqldump --extended-insert --extended-insert-multiline mydb > dump.sql

7.8 CSA 迁移踩坑清单（从 MTA 过来的真实视角）

1. binlog 格式没改干净就切 CSA：切换后应用器报错或不消费。先确认 binlog_format=ROW，且通道内没有历史 statement 事件残留（SHOW BINLOG EVENTS 抽查）；
2. 大事务是提交序的「木桶底」：CSA 的乱序应用只作用于应用阶段，提交仍严格按序。一个 10GB 大事务会拖住其后所有事务的提交，业务侧该拆批还是得拆批；
3. 开了 ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS 的通道不能切：先评估是否有依赖匿名事务的上游，再决定；
4. 延迟复制（SOURCE_DELAY）用户注意：CSA 不支持延迟复制，延迟通道留在 MTA 即可，不必强行迁移；
5. 级联复制链路：中间层从库若用了文件位点或混合格式，下游通道切 CSA 会直接失败——先治理链路，再切应用器；
6. IGNORE_SERVER_IDS 无需再配：GTID 下已应用事务自动跳过，保留旧配置虽不报错，但没有意义；
7. 回退路径要提前演练：切换前 SHOW REPLICA STATUS FOR CHANNEL 'xx'\G 留档，回退就是 STOP REPLICA SQL_THREAD → APPLIER_VERSION=1 → START REPLICA SQL_THREAD，同样在线；
8. 监控口径要换：MTA 时代盯 replica_pending_jobs_size_max 的告警，换成盯 APPLIER_EVENT_MEMORY_LIMIT 的实际水位（Performance Schema 有对应计数），别让事件缓存悄悄打满。

八、性能优化：15 条生产级建议

CSA / 复制侧

1. CSA 只认 ROW + GTID，先把 binlog 格式和 GTID 规范到位再谈切换；
2. APPLIER_WORKER_COUNT 起步 8~16，观察 replication_applier_status_by_worker 里各 worker 的空闲占比再往上调，不要直接 1024；
3. APPLIER_EVENT_MEMORY_LIMIT 按「最大事务大小 × worker 数」估算，别低于 replica_max_allowed_packet；
4. 大事务是并行复制的天敌：超过一定阈值（如 1GB）的事务考虑拆批，否则 CSA 也救不了提交序；
5. 用 binlog_transaction_compression=ON 压缩 binlog，传输和 relay log 落盘都受益；
6. 从库开启 sync_relay_log=0（默认）即可，relay log 丢了可以从主库重拉，别为 relay log 牺牲 IO；
7. 多业务混部时按通道拆分：核心交易通道 32 worker，报表通道 4 worker，互不干扰——这是 CSA 相对 MTA 最大的运维红利。

线程池侧

8. thread_pool_size = CPU 核数起步，高并发短查询可试 1.5~2 倍核数；
9. 启用后关注 thread_pool_stall_limit 触发的次数（Performance Schema 有对应计数），频繁触发说明有慢查询卡池子，优先优化 SQL 而不是加大 stall limit；
10. 连接数 < 500 且无连接风暴的场景，线程池收益有限，别为了「新功能」而开；
11. 线程池与 max_connections 是两回事：池子控活跃线程，max_connections 控连接上限，两者都要设。

PQC 侧

12. 升级 OpenSSL 3.5+ 并先观测后强制：Tls_key_exchange_algorithm 确认走混合组再开 force_pqc；
13. 复制链路强制 PQC 前，先小范围验证主从双方版本与 OpenSSL 一致；
14. 混合组（如 X25519MLKEM768）性能开销在个位数百分比内，可接受；纯 PQC 组延迟更高，非极端合规场景不必上。

通用

15. 大版本升级前跑 mysqlcheck --check-upgrade 或官方 upgrade checker，重点核对：undo truncate log 是否在途、Clone 目标是否符合 LTS 谱系、group_replication_communication_stack 相关配置是否需要迁移。

九、总结展望

MySQL 26.7.0 是一次「换引擎盖」式的版本：

• 版本体系：CalVer 落地，26.7 = 2026 年 7 月，9.7 LTS 是最后的传统版本号，升级路径第一次可编程（MYSQL_PREVIOUS_LTS_VERSION）；
• 复制：Change Stream Applier 把并行复制从「全局一刀切」变成「按通道精细化调度」，应用/提交解耦直击 MTA 的串行提交瓶颈，1024 worker/通道 + 通道级故障隔离 + Performance Schema 白盒观测，是 8.0 引入 MTA 之后复制层最大的一次架构级更新；
• 并发：线程池正式进入社区版，配合 thread_pool_max_unused_threads=32 的新默认，高连接场景终于有了官方解法；
• 安全：TLS 1.3 PQC 覆盖五条通道，「先收割后解密」的威胁模型第一次被正面回应；
• 内核：undo truncation 头文件化、ReadView false sharing 修复、超图优化器持续补课，底层功夫没停。

展望未来，CalVer 意味着 MySQL 的发布节奏会像 Ubuntu 一样可预期：每年固定月份出新版本，LTS 与非 LTS 的边界一目了然。而 CSA 的「模块化调度与执行」设计，官方明说是为未来复制增强打地基——更聪明的依赖调度、更细的并行粒度、甚至跨通道的资源协调，都可能在后续 26.x 版本里陆续浮出水面。

对还在观望的团队，我的建议是：把 9.7 LTS 当作跳板，把 26.7.0 当作新基线，先在测试环境把「GTID + ROW + 新通道 CSA + 线程池」这套组合跑通，等 26.7.x 补丁版本攒够一个季度再上生产。数据库内核的范式迁移，从来不是一次升级，而是一次有计划的重构。

（全文完。文中版本号、特性与变量名均来自 MySQL 官方 26.7.0 Release Notes 与 Reference Manual。）