MySQL错误2005是DNS解析失败所致，非服务本身问题，主因包括主机名拼写错误、容器网络未通、/etc/hosts缺失、DNS不可用或客户端host参数非法（如空值、'.'），需按nslookup→telnet→配置顺序排查。
MySQL错误2005：Unknown MySQL server host 是DNS解析问题
这个报错根本不是MySQL服务本身出问题，而是客户端连不上指定的主机名——mysql、localhost、db.example.com这类名字系统根本查不到IP。常见于用错主机名、容器网络未打通、/etc/hosts漏配、或DNS服务不可用。
检查 hostname 是否拼写错误或不可达
最容易踩的坑是把 localhost 写成 localhsot，或者在Docker Compose里用了服务名（如 mysql），但代码里却填了 127.0.0.1（容器内 127.0.0.1 指向自己，不是MySQL容器）。
- 确认连接字符串中的
host值是否与实际运行环境匹配：本地开发常用localhost或127.0.0.1；Docker中应使用服务名（如mysql）；K8s中要用Service DNS名（如mysql.default.svc.cluster.local） - 用
ping或nslookup验证：比如运行nslookup mysql，看是否返回有效IP；若失败，说明DNS或网络层已阻断 - Linux/macOS下可临时加条
/etc/hosts记录快速验证：127.0.0.1 mysql
MySQL客户端不支持空 host 或 “.” 作为主机名
某些驱动（尤其是老版本 mysql2 或 PyMySQL）遇到 host: ''、host: '.' 或 host: 'null' 会直接抛 ERROR 2005，而不是降级走 socket 连接。
- 显式指定
host: '127.0.0.1'而非留空或用'localhost'（后者在部分系统会触发 Unix socket，但配置不对时反而失败） - Node.js 的
mysql2若想强制走 TCP，必须设host: '127.0.0.1'，不能依赖localhost自动映射 - Python 的
pymysql.connect()中，host=None或host=''会触发该错误，必须传字符串'127.0.0.1'
Docker 容器间连接失败的典型配置漏项
在 docker-compose.yml 里定义了 mysql: 服务，但应用容器启动早于MySQL就绪，或没声明正确的 networks，也会表现为 2005 —— 因为名字解析成功了，但目标端口还没开，而部分客户端会把“连接被拒”误报成“主机未知”。
- 确保应用服务加了
depends_on（仅控制启动顺序，不保证MySQL已ready） - 用
healthcheck+condition: service_healthy做真正就绪等待 - 连接字符串中
host必须和docker-compose.yml里的服务名完全一致（大小写敏感），例如服务名为db，就不能写mysql - 避免在容器内用
host.docker.internal连宿主MySQL（Windows/macOS可用，Linux需额外配置）
2005 错误表面是“找不到主机”，实际常卡在容器网络、DNS配置、或客户端对 host 参数的严格校验上。最稳的排查路径是：先 nslookup 或 getent hosts 看能否解析，再 telnet 端口确认通不通，最后才查MySQL权限和bind-address。别一上来就改 my.cnf。
