最可靠的判断方式是检查 super_read_only = ON：它由复制机制自动控制，为 ON 时表明实例正作为从库运行，且需结合 SHOW SLAVE STATUS 非空输出和 replication_applier_status 为 ON 来确认复制线程活跃。
查 SHOW SLAVE STATUS 是否有输出
最直接的判断方式：执行 SHOW SLAVE STATUS\G，看有没有返回结果。
- 如果有完整输出（哪怕
Slave_IO_Running: No），说明该实例配置过复制，是「从」角色（哪怕当前没在同步） - 如果返回空集（0 rows），基本可判定为「主」——但要注意：也可能是复制被彻底清除过（比如执行过
RESET SLAVE ALL） - MySQL 8.0.22+ 支持
SELECT * FROM performance_schema.replication_connection_status，但需先确认 performance_schema 已启用且用户有对应权限
看 read_only 和 super_read_only 的实际值
read_only 不等于「就是从库」，它只是个可手动设置的开关；真正由复制机制自动控制的是 super_read_only（MySQL 5.7+）。
- 运行
SELECT @@read_only, @@super_read_only; - 若
super_read_only = ON，几乎可以确定是正在运行的从库（MySQL 启动复制线程时会自动设为 ON） - 若
super_read_only = OFF但read_only = ON，大概率是人为设的只读主库，不是复制意义上的「从」 - 注意：
super_read_only依赖read_only，前者开启时后者必为 ON；但反过来不成立
检查复制线程是否活跃
只看状态变量不够，得确认 IO/SQL 线程是否真在跑。
- 执行
SHOW PROCESSLIST，搜索含Connect（IO 线程）或Coordinator/Worker（SQL 线程）的行 - 更准的方式是查
SELECT SERVICE_STATE FROM performance_schema.replication_applier_status，返回ON才算 SQL 线程在工作 - 即使
SHOW SLAVE STATUS显示Seconds_Behind_Master: 0，也要确认Slave_SQL_Running: Yes，否则可能只是“看起来同步了”
为什么不能只信 read_only？
因为 read_only 是个普通系统变量，可被 SUPER 权限用户随时关闭，和复制拓扑无关。
- 常见误操作：DBA 在主库上执行
SET GLOBAL read_only = ON做临时保护，结果监控脚本误判为「从库」 - 有些高可用方案（如 MHA、Orchestrator）会主动在主库切走后设
read_only = ON，此时read_only反而是主库下线的信号 - 真正可靠的信号链是：
super_read_only = ON→ 复制线程存在且活跃 →SHOW SLAVE STATUS有非空输出
别漏掉 super_read_only 这个开关——它才是 MySQL 内部用来标记“我正作为从库运行”的唯一可信标志。很多自动化脚本只查 read_only，结果在主从切换后持续误报。
