MySQL 9.7.4 起用四段式版本号：驱动无感，巡检脚本会漏
MySQL 9.7 是 LTS 系列，GA 2026-04-21。从 9.7.4 开始，服务端在原有三段版本号之外多暴露了一个精确发布标识，用于区分同一条 patch line 上先后交付的两次独立更新。文档：MySQL 9.7 Reference Manual - 1.4 What Is New in MySQL 9.7。
格式：MAJOR.MINOR.PATCH.UPDATE
四段形如 MAJOR.MINOR.PATCH.UPDATE。注意 update 段不是「有值才出现」：在支持 update 的接口上它始终存在，值为 0 时也会显式写成 0，不会省略。也就是说 9.7.4.0 和 9.7.4.1 是两个不同的精确发布，前者不应被简写成 9.7.4。
取四段值的三条路径
服务端提供了三种方式拿到完整值：
SELECT VERSION_WITH_UPDATE();
SELECT @@version_with_update;
mysqld --version-with-update
其中 version_with_update 是只读的全局系统变量。另有一组新增的客户端库 API，供需要精确标识的客户端取用。
仍是三段的地方
兼容面没有改动。VERSION()、version 系统变量、mysqld --version、经典握手协议、数字版本 ID 以及既有的 C API，都继续返回三段版本语义。
因此，任何走经典握手或 VERSION() 的链路看到的仍是 9.7.4 这个粒度。ORM、连接池和大多数驱动都属于这一类。
驱动没事，脚本有事
差异恰好在这里显现：
- 驱动和 ORM 走经典握手或
VERSION()，拿到三段值，行为不变。 - 监控、巡检、CMDB 采集脚本通常用正则从
VERSION()或mysqld --version的输出里提取版本号，例如：
grep -Eo '[0-9]+\.[0-9]+\.[0-9]+'
这条正则对 9.7.4.0 与 9.7.4.1 的输出完全一致，同一条 patch line 上的两次独立更新会被压成同一个字符串。
后果是：当一条 patch line 只灰度了一部分节点时，版本比对会认为「全部一致」，滚动升级的进度和节点间差异都看不见。
落地写法
灰度比对直接比四段字符串，不要只截前三段，也不要做数值比较：
mysql -N -e "SELECT VERSION_WITH_UPDATE();"
把每个节点的返回值与基线逐字符比较即可。
巡检脚本可以同时取两个值，三段用于兼容性判断，四段用于发布一致性判断：
SELECT VERSION(), VERSION_WITH_UPDATE(), @@version_with_update;
把 mysql_upgrade_history 纳入巡检
mysql_upgrade_history 审计文件用嵌套的 update_history 数组记录精确更新，把每次 update 级的变化留在历史里。它只做记录，不参与升级兼容性判断——兼容判断仍按三段语义走。
把这份文件一并纳入巡检，可以回答「这台实例在同一条 patch line 上被更新过几次、顺序如何」，这是三段版本号给不出的信息。