docker可以从远程仓库拉取镜像然后通过镜像快速的部署应用，非常的方便快捷，但是今天来聊聊为什么Mysql不推荐使用Docker部署这个问题。
1、数据库扩容麻烦
Mysql是用来存储的数据，docker部署Mysql之后数据不会存储在容器上，因为容器关闭之后数据就丢失了，所以容器是需要挂载到宿主机器上，如下图所示：
随着业务的持续不断的发展，Mysql难免会出现需要扩容的情况，但是扩容的时候就会出现一些困难，如下所示：
此时Mysql2是无法挂载到文件1上的，因为宿主机的数据文件是容器独占的，无法实现两个容器实例共享一份数据文件。
每个Mysql的容器都挂载了各自的文件上，如何实现文件1和文件2的数据共享呢？此时有如下的解决方案：
方案一：binlog同步
方案二：先全量dump，然后再使用binlog增量同步
方案一是不推荐使用，Mysql扩容是因为业务数据量达到瓶颈了，那么大数据量下使用binlog同步是不合适的。
方案二中全量dump数据的时候需要停机，目的是先让数据同步到另一份文件上，因为数据需要同步进而让业务在一段时间内无法使用，在某种情况下也是不合适的。
2、内存资源问题
我们都知道docker是通过应用来做隔离的，而不是通过资源做隔离的，如下图所示：
假设Mysql应用、MQ应用以及Redis应用都是docker部署的，此时上图区域的内存是三个应用共享的。这里就存在一个问题，如果MQ应用占用了80%的内存，那么Mysql和Redis就只能共用剩余20%的内存，假设这个剩余的内存不够Mysql使用，这个时候就会出现Mysql无法提供正常的服务导致整个上层的应用崩溃。
总结：
（1）从数据库扩容角度来看，由于宿主机的数据文件是容器独占的，所以多个容器就会挂载在多个宿主机文件上，尽管我们可以有方案解决宿主机文件数据共享的问题，但是数据同步方案中存在一定弊端。
（2）内存资源上来考虑，由于docker部署的应用是共享内存的，所以一旦某个应用占用内存过大就会导致其他应用因为内存不足而无法对外提供服务的问题。
（3）不是说不能使用docker部署Mysql，在某些情况下docker部署的Mysql还是比较合适的，如能够利用中间件和容器化系统能够自动伸缩、容灾、切换、自带多个节点等场景下是合适进行容器化。