MySQL客户端连接非标准端口必须显式使用大写-P参数指定端口号，如mysql -h host -P 3307 -u user -p；配置文件需在[client]段设置port=3307才对所有官方客户端生效。
MySQL客户端连接非标准端口：-P 参数必须显式传入
不指定端口时，mysql 客户端默认只连 3306，哪怕服务端明明在 3307 或 4000 运行，也会直接报错“can't connect to mysql server”，而不是提示端口不对。
必须用大写的 -P（注意不是小写 -p，后者是密码参数）显式传入端口号：
mysql -h 192.168.1.100 -P 3307 -u root -p
-
-P和端口号之间可以有空格，也可以紧挨着（-P3307），但推荐带空格，避免和用户名混淆 - 如果同时用
-p输密码，它必须放在最后，否则mysql会把后面的参数误认为密码 - Docker 环境里常见坑：容器映射端口是
-p 3307:3306，但客户端连的是宿主机的3307，服务端实际监听仍是容器内3306——此时客户端仍要填-P 3307
Python pymysql / mysql-connector-python 连非标端口：port 是独立关键字参数
很多初学者把端口拼进 host 字符串里，比如 host="127.0.0.1:3307"，这在 pymysql 中会直接抛 ValueError: invalid literal for int()，因为库要求 port 必须是整数类型、单独传入。
正确写法：
pymysql.connect(host="127.0.0.1", port=3307, user="root", password="123")
-
port参数不能是字符串，必须是int；传字符串会触发类型错误 - mysql-connector-python 同样严格，
port不接受字符串，也不支持 host 冒号拼接 - 使用 SQLAlchemy 时，URL 中端口写法是
mysql+pymysql://user:pass@host:3307/dbname——这里的:3307是 URL 规范的一部分，由 SQLAlchemy 解析后转给底层驱动，和直连驱动的参数逻辑不同
MySQL 配置文件 my.cnf 里指定端口：client 段才影响命令行工具
很多人改了 [mysqld] 段的 port=3307，以为客户端也会自动跟着连新端口，结果 mysql -u root 还是连 3306 失败。因为服务端配置不影响客户端默认行为。
要让 mysql 命令行工具默认用非标端口，得在 [client] 段加配置：
[client] port = 3307
-
[client]段对所有官方客户端命令生效（mysql、mysqldump、mysqladmin） - 不要写成
[mysql]段，那只会被mysql命令读取，mysqldump就不认 - 如果配置文件里多个段都定义了
port（比如[client]和[mysql]），以命令行参数优先，其次才是匹配最精确的段
telnet / nc 测试端口通不通：别只看连接成功就以为 MySQL 可用
用 telnet 192.168.1.100 3307 或 nc -zv 192.168.1.100 3307 能通，只说明 TCP 层可达，不代表 MySQL 服务已就绪或允许你访问。
常见假阳性场景：
- 防火墙放行了端口，但 MySQL 的
bind-address配置为127.0.0.1，导致外部无法建立 MySQL 协议连接 - MySQL 正在启动中，TCP 已监听，但还没完成初始化，此时客户端连接会被立即拒绝（错误码
HY000: Can't connect to MySQL server） - 用户权限限制了来源 IP，即使端口通，认证阶段也会失败，错误信息可能还是“Access denied”，容易误判为密码错
真正可靠的验证方式：用带 -P 的 mysql 命令尝试登录，看到欢迎 banner 才算稳。
