MySQL远程连接失败主因是权限与监听配置双重缺失：root用户默认仅含'root'@'localhost'记录，不匹配任何IP；须同时完成用户授权、bind-address设为0.0.0.0、安全组放行3306端口三步。
MySQL 默认只允许 localhost 连接，远程 IP 连不上不是网络或密码问题，而是权限和监听配置双重缺失——必须同时满足「用户授权」+「服务监听」+「端口放行」三者，缺一不可。
为什么 mysql -h 192.168.1.100 -u root -p 一定失败？
因为默认安装后，root 用户在 mysql.user 表里只有一条记录：'root'@'localhost'。这个 localhost 是特殊值，不匹配任何 IP（包括 127.0.0.1 的 TCP 连接），更不会匹配远程地址。
常见误判：
- 以为改了密码就能连 → 实际根本没走到密码校验那步，身份验证阶段就被拒
- 以为开了防火墙就 OK → 即使端口通，MySQL 服务本身拒绝 TCP 连接，照样报
Host 'xxx' is not allowed to connect
CREATE USER 和 ALTER USER 到底该用哪个？
优先用 CREATE USER 建新账号，别硬改 root；MySQL 5.7+ 直接 UPDATE mysql.user 会破坏认证插件一致性，大概率触发 ERROR 1396 或权限失效。
正确操作示例：
CREATE USER 'appdb'@'192.168.1.50' IDENTIFIED BY 'StrongPass!2026'; GRANT SELECT, INSERT, UPDATE ON appdb.* TO 'appdb'@'192.168.1.50'; FLUSH PRIVILEGES;
关键点：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
'appdb'@'192.168.1.50'比'%'安全得多，明确限定来源 IP - MySQL 8.0 默认用
caching_sha2_password，如果客户端（如旧版 Navicat）不支持，需额外执行：ALTER USER 'appdb'@'192.168.1.50' IDENTIFIED WITH mysql_native_password BY 'StrongPass!2026'; -
FLUSH PRIVILEGES必须执行，否则内存缓存不更新，改了等于白改
bind-address = 0.0.0.0 不是万能解药
即使用户权限全开，mysqld 默认仍可能只监听 127.0.0.1，导致所有远程 TCP 请求被内核直接丢弃。查配置文件（/etc/mysql/mysql.conf.d/mysqld.cnf 或 /etc/my.cnf）确认以下两项：
-
bind-address = 0.0.0.0（监听全部 IPv4 接口）或具体内网 IP（如192.168.1.100） -
skip-networking这行必须被注释或删除——它一旦启用，MySQL 就彻底禁用 TCP/IP，只走 socket
改完必须重启服务：sudo systemctl restart mysql（Debian/Ubuntu）或 sudo systemctl restart mysqld（CentOS/RHEL）。
云服务器连不上？安全组比防火墙还关键
本地 ufw 或 firewalld 放行 3306 端口只是第一步。阿里云、腾讯云等平台的安全组是独立于系统防火墙的第二道关卡，且默认拒绝所有入方向流量。
必须手动添加规则：
- 协议：TCP
- 端口范围：
3306/3306 - 源 IP：不要填
0.0.0.0/0，至少限制为办公 IP 或应用服务器内网段（如192.168.10.0/24）
安全组规则生效无延迟，但很多人卡在这里反复调试 MySQL 配置，却忘了登录控制台点几下鼠标。
最容易被忽略的是：MySQL 8.0 的密码认证插件与客户端兼容性，以及云服务商安全组的独立性——这两点不验证，其他所有配置都白做。
