MySQL容器化之后的缺点_容器化的MySQL性能如何？

说到部署，Docker将便携性和易用性拉高到一个新水准。MySQL相关的Dockerfile和脚本已经发布很长时间，在开发社区的使用率也稳步增长。这一点也在意料之中。

在影响到MySQL性能的每个环节上，用户的典型担忧在于：容器化以后，在这些环节上是否存在显著的性能开销。为此，我们进行了充分的性能测试，下面我会对测试结果的某些细节进行探讨。

我们的关注点主要在MySQL实例的IO和网络性能，尤其是对比采用了不同存储选项的实例，以及docker bridge网络模式带来了多少性能开销。测试的运行环境是：Oracle Server x5-2，处理器为2x Xeon E5-2660 v3(40硬件线程)，256G内存，操作系统Ubuntu 16.04，Docker版本v1.11.2。

Docker有三种使用存储卷的方式：

1. 默认是通过使用数据卷。使用Docker内部volumes管理功能，将数据写入宿主机的某个目录。

2．指定宿主机上的一个目录，将其挂载到容器内的特定位置。

3．创建一个数据卷容器，然后将数据卷共享给其它容器。

Docker 镜像是由一组layer构成，每一个layer代表文件系统的差异。Docker的存储驱动负责叠加这些layer，进而构成一个镜像。然而，跳过docker存储驱动的数据卷和宿主机目录，在性能上接近原生的存储。AUFS是使用最广泛的docker驱动程序，因此我们使用它进行测试。

为了测试网络开销，我们分别对Docker host和bridge网络进行了测试，方法是创建容器时分别指定--net=host 或--net=bridged。创建容器