MySQL Docker容器反向主机名查找配置问题及相关疑问

问题 #

我正尝试配置官方MySQL Docker容器，为每个微服务设置专属用户，仅允许对应微服务通过该用户连接。我认为将Docker-compose.yml中定义的Docker服务名与MySQL内置的主机限制功能结合使用是合理的。

因此我在MySQL中创建了用户：

CREATE USER 'user1'@`docker_service_name` IDENTIFIED BY 'my_password';
GRANT SELECT ON `my_database`.* to 'user1'@`docker_service_name`;

当我从docker_service_name服务尝试连接时，收到错误：

SQLSTATE[HY000] [1045] Access denied for user 'user1'@'172.19.0.6' (using password: YES) (Connection: mysql, SQL: select * from `table1` where exists (.....)

这是合理的，因为允许从任意地址连接的用户并不存在（我也不希望创建这类用户）。

调研后发现官方MySQL 5.7镜像的Dockerfile中添加了配置：

#don't reverse lookup hostnames, they are usually another container
&& echo '[mysqld]\nskip-host-cache\nskip-name-resolve' > /etc/mysql/

我不理解为何要以“它们通常是其他容器”为由禁用反向主机名查找，请问原因是什么？如果我启用该功能会有什么危害吗？

解答 #

禁用反向主机名查找的原因 #

• 容器网络的DNS特性：Docker容器的服务名依赖内置DNS解析，但容器IP是动态分配的，重启后会变化，且大部分容器没在外部DNS注册主机名，反向解析（IP查主机名）通常会失败，没有实际意义。
• 性能与稳定性保障：启用反向查找后，MySQL每次处理连接都会触发DNS请求，若DNS响应慢或不可用，会直接导致连接超时、响应延迟，甚至无法正常提供服务，严重影响可用性。
• 容器环境的访问控制逻辑：在容器编排场景中，服务间的访问控制更多依赖Docker网络策略（比如自定义网络、端口限制），而非MySQL的主机名限制。官方镜像优先保证连接的稳定性和性能，因此默认禁用反向查找。

启用反向主机名查找的潜在危害 #

• 连接延迟升高：每个新连接都会额外触发DNS反向解析，高并发场景下会显著拉长连接建立时间，降低MySQL的处理效率。
• 连接失败风险增加：若Docker DNS故障，或客户端IP无法反向解析到对应服务名，MySQL会因权限匹配失败拒绝连接，导致业务服务无法访问数据库。
• 动态IP适配混乱：容器重启后IP变动，即使反向解析成功，频繁变化的IP也会导致权限匹配逻辑混乱，依然可能出现权限验证失败的问题。

内容的提问来源于stack exchange，提问作者St. Jan