mysql写入慢的真正卡点是宿主机i/o调度器，cfq或bfq会导致redo log fsync积压、await飙升；需在宿主机将nvme设为none、sata ssd设为noop或deadline，并重启mysqld进程生效。
宿主机I/O调度器是MySQL写入慢的真正卡点
MySQL在Docker里写入慢，90%不是容器配少了内存或CPU，而是宿主机块设备的I/O调度器在拖后腿。InnoDB频繁对Redo Log做fsync()，遇到cfq或bfq调度器就会排队积压，await飙到20ms+，Log sequence number和Log flushed up to差值持续超10MB就是典型信号。
确认方式：cat /sys/block/nvme0n1/queue/scheduler（把nvme0n1换成你MySQL数据盘对应设备名）；改法必须在宿主机执行，容器内操作无效：
- NVMe SSD：设为
none，命令：echo none > /sys/block/nvme0n1/queue/scheduler - SATA SSD：优先
noop，次选deadline；严禁cfq/bfq - 机械盘（不推荐）：保留
deadline，但要接受天然延迟
注意：/var/lib/docker和MySQL数据目录不能挂载在同一物理设备上，否则元数据IO和Redo IO会互相干扰。
不重启MySQL进程，调I/O调度器等于白干
InnoDB启动时探测底层设备的fsync行为并缓存能力，运行中改/sys/block/xxx/queue/scheduler对已加载引擎完全无感知。必须重启MySQL主进程——不是docker restart，而是精准杀掉mysqld：
-
docker exec -it mysql kill -15 1（假设PID 1是mysqld） - 或进容器执行
kill -15 $(pidof mysqld)后再拉起
验证是否生效：用pt-stalk抓fsync()耗时，从20ms降到1ms以内才算成功。同步调整MySQL参数才能放大收益：innodb_log_file_size=1G、innodb_log_buffer_size=64M、禁用innodb_flush_method=O_DSYNC改用O_DIRECT。
Docker默认桥接网络让MySQL连接慢10秒
外部连接MySQL延迟10秒，但容器内mysql -h 127.0.0.1秒连？八成是DNS反向解析惹的祸。MySQL默认开启skip-name-resolve=OFF，每次新连接都会尝试反查客户端IP的hostname，而Docker桥接网络的iptables规则和DNS配置常导致这个查询卡住。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
解决方法有三，按优先级排列：
- 在MySQL容器启动时加
--skip-name-resolve参数（最直接） - 改
my.cnf，显式写skip_name_resolve = ON - 若必须保留域名解析，确保宿主机
/etc/hosts里有客户端IP映射，或容器DNS配置指向稳定内网DNS
别碰bind-address设0.0.0.0这类操作——它不解决延迟，反而扩大攻击面。
Host网络模式能砍掉80%网络开销
Docker默认bridge网络引入veth pair + iptables + NAT三层转发，实测延迟比host模式高5倍（85μs vs 15μs）。对延迟敏感的场景，比如读写分离中间件直连MySQL，应强制使用host网络：
docker run --network host ... mysql:8.0-
docker-compose.yml里写
network_mode: "host"，删掉ports字段（端口直接暴露在宿主机）
副作用是容器失去网络隔离，但MySQL本就不该暴露在公网——只要宿主机防火墙（ufw或iptables）策略收紧，风险可控。若用Kubernetes，等价方案是hostNetwork: true + hostPort。
真正容易被忽略的是：网络和IO优化必须一起动。单改调度器不调innodb_log_file_size，或单切host网络却不关skip-name-resolve，都只能解一半问题。
