网络带宽限制是MySQL查询“最后一公里”瓶颈，直接导致大结果集传输慢、高并发下TCP重传增多、QPS上不去；需优先切内网、压缩传输，再考虑升级带宽。
网络带宽限制会直接卡住 MySQL 查询的“最后一公里”——结果返回环节，尤其在大结果集、高并发或跨网段访问场景下，吞吐量下降不是次要因素，而是瓶颈本身。
大结果集查询时带宽成为硬性上限
MySQL 服务端执行完 SELECT 后，数据要通过 TCP 连接批量发给客户端。如果单次查询返回 10MB 数据，而网络带宽只有 10Mbps（约 1.25MB/s），理论最小传输时间就是 8 秒——这还没算协议开销和延迟。此时 show processlist 里该连接会长期处于 Sending data 状态，CPU 和磁盘压力可能很低，但 QPS 却上不去。
- 典型现象：
SHOW STATUS LIKE 'Bytes_sent'增长缓慢，Threads_running持续偏高，但Innodb_buffer_pool_read_requests并不激增 - 验证方式：用
tcpdump抓包观察实际吞吐，或对比内网直连 vs 公网访问的相同查询耗时 - 关键区别：这不是 SQL 执行慢，是“执行完了送不出去”
高并发连接放大带宽争用效应
每个连接都在抢同一块出口带宽。假设服务器带宽为 100Mbps，单个查询平均返回 500KB，那么理论上最多支撑约 25 个并发连接把带宽跑满（100Mbps ÷ (500KB × 8) ≈ 25）。一旦超过，就会出现 TCP 重传、窗口收缩、RTT 上升，进一步降低有效吞吐。
- 容易被忽略的点：
max_connections调得再高也没用，带宽撑不住时新连接可能卡在三次握手或首包发送阶段 - 监控线索：
netstat -s | grep -i "retransmitted"显著升高，ss -i显示大量连接的cwnd值停滞不涨 - 不要只看 MySQL 的
Threads_connected，更要查/proc/net/dev中对应网卡的tx_bytes增速是否已达上限
跨地域或云环境下的隐性带宽损耗
腾讯云、阿里云等平台的“带宽”常指公网出口配额，而内网带宽（如 VPC 内）通常是无限制的。但若应用和数据库部署在不同可用区甚至不同地域，流量仍要走骨干网链路，实际可用带宽远低于标称值，且受运营商路由影响波动大。
- 常见误判：看到云控制台显示“带宽使用率 30%”，就认为网络没问题——但那只是峰值统计，瞬时打满仍会导致丢包
- 真实瓶颈点往往在中间链路：比如从北京 IDC 到上海 ECS 的跨城专线实际吞吐只有标称带宽的 60%～70%
- 解决方案优先级：先切内网连接 → 再压缩结果（如用
mysql --compress）→ 最后才考虑升级带宽
真正难处理的是带宽问题常常伪装成“数据库慢”。你优化了索引、调大了缓冲池、关掉了查询缓存，却发现 SELECT * FROM huge_table LIMIT 10000 还是卡在 2 秒以上——这时候该盯的不是 slow_query_log，而是网卡的 tx_queue_len 和丢包率。
