一、场景复现：一个让老板皱眉的TPS曲线

1.1 压测环境

• 宿主机配置：4核8G SSD云服务器，Ubuntu 20.04
• Docker MySQL：官方镜像 mysql:8.0，默认配置
• 对比组：同服务器原生安装MySQL 8.0
• 工具：sysbench 模拟1000万数据，100并发读写

1.2 结果对比（关键指标）

老码农点评：TPS看似只降了9%，但延迟飙升38%——对实时业务简直是噩梦！

二、刨根问底：Docker吃掉性能的4只“蛀虫”

2.1 网络栈：Bridge模式的隐形税

• 问题：Docker默认的bridge网络需经过NAT转发，增加2~3ms延迟。
• 实测对比：

# 使用host网络模式  
docker run --network=host mysql:8.0  

• 结果：延迟下降22%，TPS提升7%

2.2 文件系统：Overlay2的双重写入惩罚

• 原理：Docker的联合文件系统（Overlay2）会导致写操作额外复制元数据。
• 优化方案：

# 1. 数据卷直连宿主机  
docker run -v /mnt/ssd/mysql:/var/lib/mysql mysql  

# 2. 使用性能模式挂载  
mount -o noatime,data=writeback /dev/sdb /mnt/ssd  

• 效果：IO吞吐提升31%

2.3 CPU调度：CGroup的温柔陷阱

• 坑点：默认CPU配额限制导致高负载时争抢资源。
• 救命配置：

# 允许容器突破CPU限制（慎用！）  
docker run --cpus=4 --cpu-quota=-1 mysql  

2.4 内存竞争：Swap的死亡螺旋

• 案例：当容器内存超限时，Docker强制触发Swap，性能断崖式下跌。
• 硬核建议：

# 限制内存并禁用Swap  
docker run -m 4g --memory-swap=4g mysql  

三、实战：将性能损失压缩到3%的配置模板

3.1 终极docker-compose.yml

version: '3.8'  
services:  
  mysql:  
    image: mysql:8.0  
    network_mode: "host"  
    volumes:  
      - /mnt/nvme/mysql:/var/lib/mysql  
    environment:  
      - MYSQL_INNODB_FLUSH_LOG_AT_TRX_COMMIT=2  
    deploy:  
      resources:  
        limits:  
          memory: 6G  
          cpus: '3'  
    command:  
      --innodb_buffer_pool_size=4G  
      --innodb_flush_method=O_DIRECT  

3.2 调优后性能对比

四、结论：什么时候该用/不该用Docker跑MySQL？

✅ 推荐场景

• 开发/测试环境：牺牲3%性能换秒级环境重建，血赚！
• 中小规模Web应用：日均百万PV以下无压力
• 云原生技术栈：K8s生态红利远大于性能损耗

❌ 劝退场景

• 金融级高频交易：延迟多1ms都可能损失百万
• 超大规模数据分析：Hadoop/Spark直连物理机才是王道
• 老旧机械硬盘服务器：IO性能本就吃紧，别让Docker雪上加霜

五、互动时间

“你愿意用5%的性能换取容器化的便利吗？在评论区说出你的选择！”