宿主机i/o调度器是mysql写入慢的真正卡点，需将nvme设为none、sata ssd设为noop或deadline，并重启mysqld进程生效；同时配合host网络模式、tcp参数调优及innodb核心参数优化。
Host 网络本身不直接提升数据库读写性能，但它为极致读写扫清了网络层障碍——真正起决定作用的是宿主机 I/O 调度器、MySQL 内核参数与容器运行时协同配置。单纯启用 --network=host 只是第一步，漏掉后续三环，延迟和吞吐仍会卡在 I/O 或内核协议栈上。
绕开网络虚拟化，但别绕开 I/O 调度器
容器用 host 模式后，MySQL 的网络请求直通宿主机网卡，但 Redo Log 的 fsync() 依然要经过块设备调度器。NVMe 盘若还挂着 bfq，await 会飙升到 20ms+；必须在宿主机执行：
-
NVMe SSD：执行
echo none > /sys/block/nvme0n1/queue/scheduler（替换为实际设备名） -
SATA SSD：设为
noop或deadline，禁用cfq/bfq - 改完必须重启
mysqld进程（docker exec mysql kill -15 1），否则 InnoDB 不感知新调度行为
绑定真实网卡 + 关键 TCP 参数调优
host 模式下，MySQL 实际监听的是宿主机 eth0 或特定网卡，需配合内核参数释放协议栈瓶颈：
- 监听地址不写
127.0.0.1，而用宿主机局域网 IP（如192.168.1.100），避免本地回环路径干扰 - 在
/etc/sysctl.conf中追加：-
net.core.rmem_max = 134217728（接收缓冲区） -
net.core.wmem_max = 134217728（发送缓冲区） -
net.ipv4.tcp_tw_reuse = 1（缓解短连接端口耗尽） -
net.ipv4.tcp_window_scaling = 1（保障高带宽利用率）
-
- 执行
sysctl -p生效
容器内 MySQL 启动参数必须匹配物理层能力
host 模式让容器“看见”真实硬件，但 MySQL 默认配置仍按虚拟环境保守估算。需显式覆盖：
-
innodb_log_file_size = 1G（增大 Redo 日志，减少 checkpoint 频率） -
innodb_log_buffer_size = 64M（降低 log buffer 刷盘压力） -
innodb_flush_method = O_DIRECT（跳过页缓存，避免双缓冲） -
skip-name-resolve（禁用 DNS 反查，避免桥接网络下连接卡顿）
验证是否真生效，而不是“看起来跑起来了”
只看 docker ps 和 mysql -h 192.168.1.100 成功没用，要量化：
- 用
pt-stalk抓fsync()耗时：从 20ms → 压到 1ms 以内才算 I/O 调优成功 - 用
iperf3测网络吞吐：docker run --rm --network=host networkstatic/iperf3 -c 外部目标IP -P 4，确认接近物理网卡极限（如万兆达 9.2Gbps+） - 查
SHOW ENGINE INNODB STATUS中Log sequence number和Log flushed up to差值，稳定 ≤ 2MB 表示 Redo 写入无积压
