网络带宽瓶颈表现为Retrieved_Gtid_Set与Executed_Gtid_Set接近但Seconds_Behind_Master持续偏高，说明IO线程未获取新binlog；需用iftop比对主库binlog增长速率与从库3306端口接收速率，结合mtr检测丢包和抖动，且slave_compressed_protocol生效需主从版本、配置及数据可压缩性均满足条件。
网络带宽瓶颈的典型表现不是Seconds_Behind_Master高，而是Retrieved_Gtid_Set和Executed_Gtid_Set几乎同步、但Seconds_Behind_Master却持续偏高——这说明IO线程根本没拿到新binlog，不是“拿来了跑不动”，是“压根没传过来”。
怎么看Retrieved_Gtid_Set和Executed_Gtid_Set差距是否异常
在从库执行SHOW SLAVE STATUS\G，提取两行：
Retrieved_Gtid_Set: 3e1a2b3c-4d5e-6f7a-8b9c-0d1e2f3a4b5c:1-1005Executed_Gtid_Set: 3e1a2b3c-4d5e-6f7a-8b9c-0d1e2f3a4b5c:1-1004
差值只有1个事务，但Seconds_Behind_Master: 42，这就高度可疑。此时别急着调SQL线程，先查网络。
注意：Retrieved_Gtid_Set为空或远落后于主库SELECT @@GLOBAL.GTID_EXECUTED，才真正说明IO线程卡在拉取环节；若已接近，问题大概率不在带宽。
用iftop -P 3306盯实时吞吐是否匹配binlog写入速率
主库binlog每秒写多少，决定了从库IO线程最低需要多少带宽。光看iftop峰值没用，得比对“稳定流”：
- 在主库执行
SHOW MASTER STATUS记下当前File（如mysql-bin.000042）和Position - 等60秒后再次执行，算出文件增长字节数 → 除以60 → 得到平均B/s
- 在从库运行
iftop -P 3306 -t -s 60，观察主从IP间3306端口的60秒平均接收速率
如果从库iftop值长期低于主库binlog增长速率的80%，且Slave_IO_Running状态频繁在Waiting for master to send event和Connecting之间跳变，基本可锁定带宽不足或链路抖动。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
为什么slave_compressed_protocol=ON开了也没用
压缩不是开关一按就生效，它依赖两端协议协商，常见失效点：
-
slave_compressed_protocol=ON必须写在从库my.cnf的[mysqld]段并重启，SET GLOBAL动态设置无效 - 主库MySQL版本必须≥8.0.20；5.7或8.0.19以下不支持zstd压缩协商，即使从库配了也退回到未压缩流
- 主库
max_allowed_packet太小（如默认4MB），可能截断压缩后的包，导致IO线程报错Lost connection to MySQL server during query - 数据本身不可压缩（比如大量
BLOB、JSON字段已加密或base64编码），实测压缩率
验证是否真启用：执行SHOW SLAVE STATUS\G，看Slave_IO_State里是否出现Waiting for master to send event (compressed)字样。
丢包和抖动要连续测，不能只看单次ping
ping只能反映ICMP层连通性，对MySQL长连接无参考价值。必须用mtr持续观测：
- 运行
mtr --report-cycles 300 主库IP（300秒≈5分钟） - 重点关注
Loss%列：>0.5%丢包率，或Best/Avg/Wrst中任意一栏抖动>5ms，都足以让IO线程反复重传、超时重连 - 特别留意中间跳点（如交换机、防火墙）是否出现集中丢包——千兆共享交换机在流量突增时容易成瓶颈，而专用网卡直连通常更稳
真实生产中，很多“网络没问题”的判断，都源于只跑了3次ping就下结论。带宽瓶颈往往藏在毫秒级抖动和零星丢包里，必须用mtr这类工具抓稳态表现。
